How not to implement two-factor authentication using the example of one bank, or why the product manager should consult with security guards
For the fourth year I have been a client of one bank. At one time there were a lot of jambs in the UI, about which I wrote to the bank multipage reviews (and even now programmers cannot realize what any Russian schoolchild who writes a calculator for the first time does: namely, take as a decimal separator and period , and a comma), but compared to the rest of the fear of Sberbank, Raiffeisen (oh, these java applets, how many acquaintances called each time they needed to make a transfer — they could not figure it out), etc., joy for the eyes.
But, actually, the post got out of the recent "improvement". A month or two ago, someone at the bank decided to improve user interaction and send one-time codes for certain operations not through es-es-esk, but through a USSD message (UPDATE: or, as suggested in the comments, perhaps via Flash-SMS, that However, it does not change matters). Here the defense began to fall.
When USSD messages were used:
In all other cases, a good old SMS is used to send a one-time password.
')
It is important to understand the purpose of USSD. The main direction of using the USSD service is to provide subscribers with the opportunity to receive additional information from applications and manage these applications. That is, find out the balance, perform a series of actions (walk through the menu), order some kind of service.
The key point is that the USSD should (but not in this bank) be initiated by the user himself on a specific device (i.e. the user must hold the device in his hands at that moment). This is because USSD is, in essence, a signaling channel, in which the exchange of messages occurs instantaneously and, unlike SMS, the USSD does not have an intermediate database. Simply put, they are not stored anywhere and are shown “here and now”, being delivered instantly.
On the one hand, everything is fine: a one-time password will not be saved in any database, it will come faster than SMS, the entire dialogue will be conducted within one session, you will not need to exit the mobile application (text over USSD will appear on the interface). But there is one thing, because the USSD message is not stored anywhere, it is shown instantly and immediately on top of any interface (as in the picture above; God forbid, spammers will start sending their “letters” via USSD). If it is not yet clear, the USSD message will be shown, even if your phone is locked with a password (SMS text, and with it a one-time password, when the phone is locked, not read), at least on iOS and, as suggested in the comments, on Windows Phone.
Therefore, if an attacker suddenly recognized your regular password and at the same time has physical access to your phone for 5 seconds (for example, you left it on the table and moved away), he will be able to enter the mobile bank. Even if your phone is password-protected. And he doesn’t even need to delete the USSD message, since it will not be saved anywhere on the phone, but will simply disappear when you press the Dismiss button. Again, due to the fact that the message will be shown forcibly (the SMS itself will not open while you are playing, for example), you can simply be near the phone (in this case, however, the victim suspects something, because she did not initiate message).
Do you think the problems are over? Someone "ingenious" from the interaction department decided to make the service even more convenient. “Let's only ask for a one-time login password the first time the user installed the application,” he said. He said, but did not think: what if this user entered his personal account not through his tablet / phone? If this was an intruder's device, then now, to log in, it would be enough for him to know the user's ordinary password (two-factor authentication will simply not be requested).
As a result, a wonderful scheme is happening now:
1. We introduce two-factor authentication (type).
2. We will send a one-time password via USSD, not SMS, so that the code can be seen even on a locked phone. That's right for current clients on Windows 8 and Android, but already corrected for the latest version of the client under iOS.
3. We will not ask for a one-time password if we have entered the device at least once using two-factor authentication (that is, we will formally disable two-factor authentication for a specific device).
4. Make the victim go through our device and find out its password (there was a wonderful video about software that “removes” the typed password by reflecting the screen in the glasses or the keylogger).
5. Profit!
1. While there is a similar behavior, at least in iOS and Windows Phone, always use SMS (and only SMS) to transfer one-time passwords.
2. If the user has already agreed to a two-factor authorization, always use it (do not disable it for individual devices after the first login if the user has left his “profile”). This is a much more serious violation of security policy than sending USSD passwords (after all, in this case you don’t need to send anything at all).
Bank, if anything, Tinkov. Hence the moral, if all this bothers you, use only a web-muzzle (there always comes only SMS and always requires two-factor authentication). How does the caliper respond: “At the moment, to make the appropriate changes, unfortunately, is not possible.” I hope this post will somehow raise the priority of "relevant changes" from "someday, if there is time" to "urgent."
Update: a bank employee considers such breaches of security as “dubious bugs” in the comments and considers it normal to consider authorized any device where you have entered a confirmation code at least once (you will never use someone else’s tablet / phone). Well done, what.
But, actually, the post got out of the recent "improvement". A month or two ago, someone at the bank decided to improve user interaction and send one-time codes for certain operations not through es-es-esk, but through a USSD message (UPDATE: or, as suggested in the comments, perhaps via Flash-SMS, that However, it does not change matters). Here the defense began to fall.
When USSD messages were used:
- Upon initial login on a mobile device.
- When performing transactions through a mobile client (for confirmation).
In all other cases, a good old SMS is used to send a one-time password.
')
What was wrong
It is important to understand the purpose of USSD. The main direction of using the USSD service is to provide subscribers with the opportunity to receive additional information from applications and manage these applications. That is, find out the balance, perform a series of actions (walk through the menu), order some kind of service.
The key point is that the USSD should (but not in this bank) be initiated by the user himself on a specific device (i.e. the user must hold the device in his hands at that moment). This is because USSD is, in essence, a signaling channel, in which the exchange of messages occurs instantaneously and, unlike SMS, the USSD does not have an intermediate database. Simply put, they are not stored anywhere and are shown “here and now”, being delivered instantly.
On the one hand, everything is fine: a one-time password will not be saved in any database, it will come faster than SMS, the entire dialogue will be conducted within one session, you will not need to exit the mobile application (text over USSD will appear on the interface). But there is one thing, because the USSD message is not stored anywhere, it is shown instantly and immediately on top of any interface (as in the picture above; God forbid, spammers will start sending their “letters” via USSD). If it is not yet clear, the USSD message will be shown, even if your phone is locked with a password (SMS text, and with it a one-time password, when the phone is locked, not read), at least on iOS and, as suggested in the comments, on Windows Phone.
Therefore, if an attacker suddenly recognized your regular password and at the same time has physical access to your phone for 5 seconds (for example, you left it on the table and moved away), he will be able to enter the mobile bank. Even if your phone is password-protected. And he doesn’t even need to delete the USSD message, since it will not be saved anywhere on the phone, but will simply disappear when you press the Dismiss button. Again, due to the fact that the message will be shown forcibly (the SMS itself will not open while you are playing, for example), you can simply be near the phone (in this case, however, the victim suspects something, because she did not initiate message).
Never make exceptions for two-factor authentication for the convenience of users.
Do you think the problems are over? Someone "ingenious" from the interaction department decided to make the service even more convenient. “Let's only ask for a one-time login password the first time the user installed the application,” he said. He said, but did not think: what if this user entered his personal account not through his tablet / phone? If this was an intruder's device, then now, to log in, it would be enough for him to know the user's ordinary password (two-factor authentication will simply not be requested).
As a result, a wonderful scheme is happening now:
1. We introduce two-factor authentication (type).
2. We will send a one-time password via USSD, not SMS, so that the code can be seen even on a locked phone. That's right for current clients on Windows 8 and Android, but already corrected for the latest version of the client under iOS.
3. We will not ask for a one-time password if we have entered the device at least once using two-factor authentication (that is, we will formally disable two-factor authentication for a specific device).
4. Make the victim go through our device and find out its password (there was a wonderful video about software that “removes” the typed password by reflecting the screen in the glasses or the keylogger).
5. Profit!
Conclusion
1. While there is a similar behavior, at least in iOS and Windows Phone, always use SMS (and only SMS) to transfer one-time passwords.
2. If the user has already agreed to a two-factor authorization, always use it (do not disable it for individual devices after the first login if the user has left his “profile”). This is a much more serious violation of security policy than sending USSD passwords (after all, in this case you don’t need to send anything at all).
Bank, if anything, Tinkov. Hence the moral, if all this bothers you, use only a web-muzzle (there always comes only SMS and always requires two-factor authentication). How does the caliper respond: “At the moment, to make the appropriate changes, unfortunately, is not possible.” I hope this post will somehow raise the priority of "relevant changes" from "someday, if there is time" to "urgent."
Update: a bank employee considers such breaches of security as “dubious bugs” in the comments and considers it normal to consider authorized any device where you have entered a confirmation code at least once (you will never use someone else’s tablet / phone). Well done, what.
Source: https://habr.com/ru/post/188198/
All Articles