How to try to make the user comfortable and bungle something in the process.
Any application update should carry something meaningful. At least so that the changelog was more informative than “Minor fixes and improved stability”. After all, once a new iteration of an application rolls out, it would be nice to even superficially explain to the user what exactly is new in it.
In 2016, we decided to seriously upgrade one of the critical functions of the Alfa Mobile mobile application, namely, authorization and registration of new users. The aspirations of the venture were the best that was best - and it was convenient to make the user and catch up with a couple of other banks whose authorization took place under a new scheme.
The result was the drop in the app rating in the app store from 4 stars to 1.5, a lot of disgruntled reviews and a slightly grayed-out product.
')
And that's how it was.
For a long time, the problem that caused some inconvenience was that client registration in the mobile application was a rather offline process. The person had to get a piece of paper with a pair of “login-password” at the bank’s office (or using an ATM) and then use this data to log into the application. The paper could successfully lose or zanyk somewhere (important thing) so that later they could not find, the password was too lazy, and the person simply did not use the mobile for this reason.
We decided to rework the authorization process, all the more so that the entrance to the application by the PIN code and then by fingerprint, and not by login and password, became the trend in the market.
We have a lot of commands that saw solutions for the web, of course, technically, you can code at the same time and under the web and under the mobile, and then just open the necessary features on the mobile, but it was with authorization that it happened a little differently - its old model was adapted for scaling.
We used the technology of new authorization on our other project, Sense, it showed itself well, and we realized that we need to go in the direction of OAuth 2.0 - the client should have a single authorization point in all applications of the bank. This would solve a large number of problems, both internal and external.
I wanted to make it so that the user could immediately enter the application without going to a branch or interacting with an ATM, using available tools. That is a card and phone.
For a couple of months, we were finalizing the Sense authorization server to adapt the new authorization to the mobile with the ability to scale, to make the right flow of work with the client and bring everything to OAuth 2.0 standards. Why did you choose OAuth 2.0, the protocol widely used by leading technology companies, there are many case studies inside it. When you fulfill all the requirements of the standard, you already close a bunch of security problems.
As soon as we did all this, in December 2016 we opened a new registration for users. The general launch was successful, the metrics were pleasing to the eye, users stopped scoring for registration and became active users, and not just a line in the database. There was a need to transfer current clients to a new authorization system - the goal was to scale the webview and make a single middle for all channels.
Of course, there were a number of problems with conservative clients who got used to the login, and all other authorization options were considered heresy and interference with privacy. The transition process was made very simple - no new registration, it was enough to log in with the familiar “Login-password” pair, enter the code from the SMS and enter the desired PIN-code on the new page, which henceforth became the login data.
From a security point of view, everything is fine here - you have both the entry point and the form page itself located in the contour of the bank. All authorizations to the bank are made through a single authorization page on webview. We have tried to save the user experience from mobile applications on webview so that the user does not have a dissonance about the fact that the web opens, not a mobile.
We encountered several problems: some users considered the 4-digit pin unsafe, so we introduced the ability to use a pin of 4 to 8 characters, another part of users requested the ability to log in under different accounts from the same device, there were also users with several devices, which was inconvenient to be registered every time on the new device.
On Android, everything was fine (again, except for those who do not want to give up the login password in favor of a pin).
But there was a problem with iOS.
For successful authorization with the help of Apple Watch, we encrypted the client's password in Keychain, the storage is good, reliable, not yet compromised. The password hash was stored there, and when the client, say, from the clock, tried to check the account balance - we passed the password - authorized the user - showed the balance.
And after rolling out the new authorization to the clients from iOS, a rather sudden fact occurred.
How everything should have been ideally:
How come
This did not happen to all users, of course, but it did.
As a result - a number of not very positive reviews in the AppStore. Yes, the cherry on the cake here is the fact that at that time, Apple did not give the developer the opportunity to respond to a review. That is, you see that a specific review of a real problem has been written to your application, but you cannot clarify something with the user. Not at all. It remains only to read and wish that all this quickly ended.
Which is characteristic - the complete reinstallation of the application helped. The user deleted the application from the device, put the same version, and everything worked.
But authorization is primary. You may have a lot of bugs in the application itself, but if you have a bug in authorization, the user simply will not get to the rest.
We debugged. We tried to recreate different scenarios on test accounts. We sinned on the old Keychain handler, which vendors wrote for us, and on Keychain himself (we found a bug with Apple, they had it in Jira, sometimes in fact the information is not stored in Keychain) - it was still not possible to reproduce the situation exactly as the dissatisfied users described it.
On the test devices, all passwords were six-digit, the new pin on them was put four-digit.
The problem was not immediately excavated.
We saved the password hash in Keychain, the same with pin (hash + token), by entering the application. Passwords are not stored on the back-up, and only tokens go, which are updated much more often than the login and password - one token suffocates once a day, the other lives a little longer.
Some customers entered a new pin, which completely coincided with their previous password. It was not recorded as new, so the system otpingyva user to the old login page. When we caught it (almost a month and a half, yes), we began to give users an alert that the new pin did not coincide with the old password. Then corrected the problem with incorrect rewriting.
So at the moment in terms of authorization with the application everything is OK. But still there is a certain percentage of dissatisfied with innovations.
Conservatives. Well, the person does not like the new entry by pin, he wants only a login and password and that's it.
Family. There are situations when a husband and wife use one device to enter their 2 accounts. If earlier this was implemented simply by changing the login and password at the entrance, then after the pin such a procedure is now complicated - you need to re-enter through the card. Honestly, we do not know why people are doing this (at least, this puts an end to possible stashes from a wife), but the situation is not the rarest.
IPad lovers. We didn’t roll out registrations on iPads, because about 2% of users use the metrics from iPads. And some absolutely insignificant part of these 2% comes only through the iPad, and does not use it as an additional device. Now we have refused to support ipads, new features are not coming to applications for it.
It was a pretty weighty rake, but they helped us draw the right conclusions and optimize the work of the teams.
Now we are rolling out new versions, first for 5-10% of users, if everything is in order - on all the others. This usually happens like this.
Now we are releasing more often, and each release is usually some significant functions or major improvements to the current ones. Now several teams are working in parallel, without interfering with each other (we will soon tell about this too). Some projects are launched on webview and re-used on mobile.
Therefore, we are now actively looking for new employees - interface designer / iOS developer / tester / and not only .
Come to us and we will make products together.
In 2016, we decided to seriously upgrade one of the critical functions of the Alfa Mobile mobile application, namely, authorization and registration of new users. The aspirations of the venture were the best that was best - and it was convenient to make the user and catch up with a couple of other banks whose authorization took place under a new scheme.
The result was the drop in the app rating in the app store from 4 stars to 1.5, a lot of disgruntled reviews and a slightly grayed-out product.
')
And that's how it was.
Offline -> online
For a long time, the problem that caused some inconvenience was that client registration in the mobile application was a rather offline process. The person had to get a piece of paper with a pair of “login-password” at the bank’s office (or using an ATM) and then use this data to log into the application. The paper could successfully lose or zanyk somewhere (important thing) so that later they could not find, the password was too lazy, and the person simply did not use the mobile for this reason.
We decided to rework the authorization process, all the more so that the entrance to the application by the PIN code and then by fingerprint, and not by login and password, became the trend in the market.
We have a lot of commands that saw solutions for the web, of course, technically, you can code at the same time and under the web and under the mobile, and then just open the necessary features on the mobile, but it was with authorization that it happened a little differently - its old model was adapted for scaling.
We used the technology of new authorization on our other project, Sense, it showed itself well, and we realized that we need to go in the direction of OAuth 2.0 - the client should have a single authorization point in all applications of the bank. This would solve a large number of problems, both internal and external.
I wanted to make it so that the user could immediately enter the application without going to a branch or interacting with an ATM, using available tools. That is a card and phone.
For a couple of months, we were finalizing the Sense authorization server to adapt the new authorization to the mobile with the ability to scale, to make the right flow of work with the client and bring everything to OAuth 2.0 standards. Why did you choose OAuth 2.0, the protocol widely used by leading technology companies, there are many case studies inside it. When you fulfill all the requirements of the standard, you already close a bunch of security problems.
As soon as we did all this, in December 2016 we opened a new registration for users. The general launch was successful, the metrics were pleasing to the eye, users stopped scoring for registration and became active users, and not just a line in the database. There was a need to transfer current clients to a new authorization system - the goal was to scale the webview and make a single middle for all channels.
Of course, there were a number of problems with conservative clients who got used to the login, and all other authorization options were considered heresy and interference with privacy. The transition process was made very simple - no new registration, it was enough to log in with the familiar “Login-password” pair, enter the code from the SMS and enter the desired PIN-code on the new page, which henceforth became the login data.
From a security point of view, everything is fine here - you have both the entry point and the form page itself located in the contour of the bank. All authorizations to the bank are made through a single authorization page on webview. We have tried to save the user experience from mobile applications on webview so that the user does not have a dissonance about the fact that the web opens, not a mobile.
We encountered several problems: some users considered the 4-digit pin unsafe, so we introduced the ability to use a pin of 4 to 8 characters, another part of users requested the ability to log in under different accounts from the same device, there were also users with several devices, which was inconvenient to be registered every time on the new device.
On Android, everything was fine (again, except for those who do not want to give up the login password in favor of a pin).
But there was a problem with iOS.
And began
For successful authorization with the help of Apple Watch, we encrypted the client's password in Keychain, the storage is good, reliable, not yet compromised. The password hash was stored there, and when the client, say, from the clock, tried to check the account balance - we passed the password - authorized the user - showed the balance.
And after rolling out the new authorization to the clients from iOS, a rather sudden fact occurred.
How everything should have been ideally:
- User logs in, enters his login password
- Goes to the SMS input page to confirm login.
- Goes to pin input page.
- The user comes up with a pin, it is saved, we reset the password
- The user in the future is included in the application for pinu, everyone is happy.
How come
- User logs in, enters his login password
- Goes to the SMS input page to confirm login.
- Gets to the page with the introduction of a new PIN code, enters it.
- It gets to the page that asks him to enter his login and password again. Which we have already successfully dropped, and therefore it no longer works.
- Thinks about the futility of life.
This did not happen to all users, of course, but it did.
As a result - a number of not very positive reviews in the AppStore. Yes, the cherry on the cake here is the fact that at that time, Apple did not give the developer the opportunity to respond to a review. That is, you see that a specific review of a real problem has been written to your application, but you cannot clarify something with the user. Not at all. It remains only to read and wish that all this quickly ended.
Which is characteristic - the complete reinstallation of the application helped. The user deleted the application from the device, put the same version, and everything worked.
But authorization is primary. You may have a lot of bugs in the application itself, but if you have a bug in authorization, the user simply will not get to the rest.
We debugged. We tried to recreate different scenarios on test accounts. We sinned on the old Keychain handler, which vendors wrote for us, and on Keychain himself (we found a bug with Apple, they had it in Jira, sometimes in fact the information is not stored in Keychain) - it was still not possible to reproduce the situation exactly as the dissatisfied users described it.
On the test devices, all passwords were six-digit, the new pin on them was put four-digit.
The problem was not immediately excavated.
We saved the password hash in Keychain, the same with pin (hash + token), by entering the application. Passwords are not stored on the back-up, and only tokens go, which are updated much more often than the login and password - one token suffocates once a day, the other lives a little longer.
Some customers entered a new pin, which completely coincided with their previous password. It was not recorded as new, so the system otpingyva user to the old login page. When we caught it (almost a month and a half, yes), we began to give users an alert that the new pin did not coincide with the old password. Then corrected the problem with incorrect rewriting.
So at the moment in terms of authorization with the application everything is OK. But still there is a certain percentage of dissatisfied with innovations.
Conservatives. Well, the person does not like the new entry by pin, he wants only a login and password and that's it.
Family. There are situations when a husband and wife use one device to enter their 2 accounts. If earlier this was implemented simply by changing the login and password at the entrance, then after the pin such a procedure is now complicated - you need to re-enter through the card. Honestly, we do not know why people are doing this (at least, this puts an end to possible stashes from a wife), but the situation is not the rarest.
IPad lovers. We didn’t roll out registrations on iPads, because about 2% of users use the metrics from iPads. And some absolutely insignificant part of these 2% comes only through the iPad, and does not use it as an additional device. Now we have refused to support ipads, new features are not coming to applications for it.
It was a pretty weighty rake, but they helped us draw the right conclusions and optimize the work of the teams.
Now we are rolling out new versions, first for 5-10% of users, if everything is in order - on all the others. This usually happens like this.
- Beta Rollout
- On employees of Alpha Laboratory
- All Alfa-Bank employees (here the sample is more serious, after all, 25,000+ people) can collect feedback very quickly and in detail, because everyone has different devices and usage scenarios that can be skipped on tests.
Now we are releasing more often, and each release is usually some significant functions or major improvements to the current ones. Now several teams are working in parallel, without interfering with each other (we will soon tell about this too). Some projects are launched on webview and re-used on mobile.
Therefore, we are now actively looking for new employees - interface designer / iOS developer / tester / and not only .
Come to us and we will make products together.
Source: https://habr.com/ru/post/334658/
All Articles