Two-factor authentication, which is convenient to use
A rare post on Yandex’s blog, especially regarding security, did not mention two - factor authentication. We have been thinking for a long time about how to properly strengthen the protection of user accounts, and even so that it could be used without all the inconveniences that include the most common implementations today. And they, alas, are uncomfortable. According to some reports, on many large sites, the proportion of users who have included additional means of authentication does not exceed 0.1%.
It seems that this is because the common two-factor authentication scheme is too complicated and inconvenient. We tried to come up with a method that would be more convenient without losing the level of protection, and today we are presenting its beta version.
We hope it will get more widespread. For our part, we are ready to work on its improvement and subsequent standardization.
')
After enabling two-factor authentication in the Passport, you will need to install the Yandex.Key application in the App Store or Google Play . In the authorization form on the main page of Yandex, QR-codes appeared in the Mail and Passport. To log in to your account, you must read the QR code through the application - that's all. If you cannot read the QR code, for example, the camera of the smartphone does not work or there is no access to the Internet, the application will create a one-time password that will take only 30 seconds.
I’ll tell you why we decided not to use such “standard” mechanisms as RFC 6238 or RFC 4226 . How do common two-factor authentication schemes work? They are two-step. The first stage is the usual authentication with a login and password. If it is successful, the site checks whether this user session “likes” it or not. And, if you do not like it, it asks the user to "authenticate". There are two common methods of "pre-authentication": sending an SMS to an account-linked phone number and generating a second password on a smartphone. Basically, TOTP is used to generate a second password using RFC 6238. If the user has entered the second password correctly, the session is considered fully authenticated, and if not, the session also loses “preliminary” authentication.
Both ways ─ sending SMS and generating a password ─ proof of phone ownership and therefore are a factor of availability. The password entered at the first stage is the knowledge factor. Therefore, this authentication scheme is not only a two-stage, but also two-factor.
Let's start with the fact that the computer of an average user cannot always be called a sample of security: here both turning off Windows updates and a pirated copy of antivirus without modern signatures, and software of dubious origin ─ all this does not increase the level of protection. According to our estimates, the compromise of the user's computer is the most widespread way to “hijack” accounts (and recently there was another confirmation ), and I want to protect myself first of all. In the case of two-step authentication, if we assume that the user's computer is compromised, entering a password on it compromises the password itself, which is the first factor. Hence, the attacker only needs to pick the second factor. In the case of common implementations of RFC 6238, the second factor is 6 decimal digits (and the maximum stipulated by the specification is 8 digits). According to the bruteforce calculator for OTP , in three days the attacker is able to pick up the second factor if he somehow knows the first one. It is not clear that the service can counter this attack without disrupting the normal work of the user. The only possible proof of work is captcha, which, in our opinion, is the last resort.
The second problem is the non-transparency of the service's judgment about the quality of the user session and deciding on the need for “pre-authentication”. Worse, the service is not interested in making this process transparent, because after all, security by obscurity actually works here. If the attacker knows on what basis the service decides on the legitimacy of the session, he can try to falsify this data. From general considerations, it can be concluded that judgment is made based on the user's authentication history, taking into account the IP address (and the autonomous system identification number identifying the provider and location based on the geobase) and browser data, such as the User Agent header and the set of cookies, flash lso and html local storage. This means that if the attacker controls the user's computer, he has the opportunity not only to steal all the necessary data, but also to use the victim's IP address. Moreover, if the decision is made on the basis of ASN, then any authentication from a public Wi-Fi in a coffee shop can lead to “poisoning” from the point of view of security (and whitening from the point of view of service) of the provider of this coffee house and, for example, the whiteing of all coffee shops in the city . We talked about the operation of the anomaly detection system , and it could be applied, but the time between the first and second stages of authentication may not be enough for a confident judgment of the anomaly. In addition, the same argument destroys the idea of "trusted" computers: an attacker can steal any information that affects the power of attorney judgment.
Finally, two-step authentication is simply inconvenient: our usability studies show that nothing annoys users more than an intermediate screen, additional button presses, and other “unimportant” actions, from his point of view.
Based on this, we decided that the authentication should be one-step and the password space should be much larger than possible within the framework of the “pure” RFC 6238.
At the same time, we wanted to preserve, as far as possible, two-factor authentication.
Multifactorial authentication is determined by assigning authentication elements (actually, they are called factors) to one of three categories:
When we started to deal with the problem of two-factor authentication (the first pages of the corporate wiki on this issue relate to 2012, but he was discussed behind the scenes before), the first idea was to take standard authentication methods and apply them to us. We understood that it is impossible to count on the fact that millions of our users will buy a hardware token, so this option was postponed for some exotic cases (although we do not completely refuse from it, we may be able to come up with something interesting). The SMS method could not be massive either: it is a very unreliable delivery method (at the most crucial moment SMS may be delayed or not at all), and sending SMS costs money (and operators began to increase their price). We decided that the use of SMS is the lot of banks and other non-technological companies, and our users want to offer something more convenient. In general, the choice was small: use a smartphone and a program in it as the second factor.
This form of one-step authentication is widespread: the user remembers the pin code (the first factor), has a hardware or software (on the smartphone) hand token that generates OTP (the second factor). In the password entry field, he enters the pin code and the current OTP value.
In our opinion, the main drawback of this scheme is the same as that of two-step authentication: if we assume that the user's desktop is compromised, then a single pin-code entry leads to its disclosure and the attacker can only pick up the second factor.
We decided to go another way: the password is entirely generated from the secret, but only a part of the secret is saved in the smartphone, and a part is entered by the user each time the password is generated. Thus, the smartphone itself is a factor of ownership, and the password remains in the user's head and is a factor of knowledge.
Nonce can be either a counter or the current time. We decided to choose the current time, it allows not to be afraid of out of sync in case someone generates too many passwords and increases the counter.
So, we have a program for the smartphone, where the user enters his part of the secret, that is mixed with the stored part, the result is used as the HMAC key, which signs the current time, rounded up to 30 seconds. The output of the HMAC is in a readable form, and voila - this is the one-time password!
As already mentioned, RFC 4226 involves truncating the result of HMAC work to a maximum of 8 decimal digits. We decided that a password of this size is not suitable for one-step authentication and should be increased. At the same time, we wanted to maintain ease of use (after all, we recall, we want to make such a system that ordinary people will use, not just security geeks), so we chose truncating up to 8 Latin characters as a compromise in the current version of the system. It seems that 26 ^ 8 passwords that are valid for 30 seconds is quite acceptable, but if we are not satisfied with the security margin (or valuable tips will appear on Habré to improve this scheme), we will expand, for example, to 10 characters.
In fact, for caseless Latin letters, the number of options per character is 26, for large and small Latin letters plus numbers, the number of options is 26 + 26 + 10 = 62. Thenlog 62 (26 10 ) ≈ 7.9, that is, a password of 10 random small Latin letters is almost as strong as a password of 8 random large and small Latin letters or numbers. This is exactly enough for 30 seconds. If we talk about an 8-character password of Latin letters, then its strength is log 62 (26 8 ) ≈ 6.3, that is, slightly more than a 6-character password from large, small letters and numbers. We believe that this is still acceptable for a window in 30 seconds.
In general, it was possible to dwell on this, but we wanted to make the system even more convenient. When a person has a smartphone in his hand, he does not want to enter a password from the keyboard!
Therefore, we began work on the "magic login". With this authentication method, the user launches the application on the smartphone, enters his PIN code into it and scans the QR code on the screen of his computer. If the PIN code is entered correctly, the page in the browser reloads and the user is authenticated. Magic!
In the QR code, the session number is sewn up, and when the application scans it, this number is transmitted to the server along with the password and username generated in the usual way. It's easy, because the smartphone is almost always online. In the layout of the page showing the QR code, JavaScript is running, waiting for the server to respond to the password check with this session. If the server responds that the password is correct, session cookies are set along with the response, and the user is considered authenticated.
It became better, but here we decided not to stop. Starting with the iPhone 5S, the TouchID fingerprint scanner appeared in Apple phones and tablets, and in iOS version 8, it is also available for third-party applications. In fact, the application does not gain access to the fingerprint, but if the fingerprint is correct, then an additional Keychain section becomes available to the application. This we have used. The second part of the secret, the one that the user entered from the keyboard in the previous script, is placed in the KeyDain protected TouchID entry. When unlocking Keychain, the two parts of the secret are mixed, and then the process works as described above.
But the user has become incredibly comfortable: he opens the application, puts his finger, scans the QR code on the screen and is authenticated in the browser on the computer! So we replaced the knowledge factor with a biometric one and, from the user's point of view, completely abandoned passwords. We are sure that for ordinary people such a scheme will seem much more convenient than manually entering two passwords.
It is possible to discuss how formally this two-factor authentication is, but in fact for successful passage it is still necessary to have a phone and have the right fingerprint, so we believe that we have completely managed to abandon the knowledge factor, replacing it with biometrics. We understand that we rely on the security of ARM TrustZone , the underlying iOS Secure Enclave , and we believe that at the moment this subsystem can be considered trusted in our threat model. Of course, we know the problems of biometric authentication: a fingerprint is not a password and it cannot be replaced in case of compromise. But, on the other hand, everyone knows that safety is inversely proportional to convenience, and the user himself has the right to choose an acceptable ratio of the one and the other.
Let me remind you that while it is beta. Now, when enabling two-factor authentication, we temporarily disable password synchronization in the Yandex Browser. This is due to the way the password database is encrypted. We have already come up with a convenient way to authenticate the browser in the case of 2FA. All other functionality of Yandex works as before.
That's what we did. It seems, it turned out well, but to judge you. We will be happy to hear feedback and recommendations, and we will continue to work on improving the security of our services: now, together with CSP , mail transport encryption and everything else , we also have two-factor authentication . Do not forget that authentication services and OTP generation applications are critical and that is why a double bonus is paid for errors found in the Bug Bounty program.
It seems that this is because the common two-factor authentication scheme is too complicated and inconvenient. We tried to come up with a method that would be more convenient without losing the level of protection, and today we are presenting its beta version.
We hope it will get more widespread. For our part, we are ready to work on its improvement and subsequent standardization.
')
After enabling two-factor authentication in the Passport, you will need to install the Yandex.Key application in the App Store or Google Play . In the authorization form on the main page of Yandex, QR-codes appeared in the Mail and Passport. To log in to your account, you must read the QR code through the application - that's all. If you cannot read the QR code, for example, the camera of the smartphone does not work or there is no access to the Internet, the application will create a one-time password that will take only 30 seconds.
I’ll tell you why we decided not to use such “standard” mechanisms as RFC 6238 or RFC 4226 . How do common two-factor authentication schemes work? They are two-step. The first stage is the usual authentication with a login and password. If it is successful, the site checks whether this user session “likes” it or not. And, if you do not like it, it asks the user to "authenticate". There are two common methods of "pre-authentication": sending an SMS to an account-linked phone number and generating a second password on a smartphone. Basically, TOTP is used to generate a second password using RFC 6238. If the user has entered the second password correctly, the session is considered fully authenticated, and if not, the session also loses “preliminary” authentication.
Both ways ─ sending SMS and generating a password ─ proof of phone ownership and therefore are a factor of availability. The password entered at the first stage is the knowledge factor. Therefore, this authentication scheme is not only a two-stage, but also two-factor.
What seemed problematic to us in this scheme?
Let's start with the fact that the computer of an average user cannot always be called a sample of security: here both turning off Windows updates and a pirated copy of antivirus without modern signatures, and software of dubious origin ─ all this does not increase the level of protection. According to our estimates, the compromise of the user's computer is the most widespread way to “hijack” accounts (and recently there was another confirmation ), and I want to protect myself first of all. In the case of two-step authentication, if we assume that the user's computer is compromised, entering a password on it compromises the password itself, which is the first factor. Hence, the attacker only needs to pick the second factor. In the case of common implementations of RFC 6238, the second factor is 6 decimal digits (and the maximum stipulated by the specification is 8 digits). According to the bruteforce calculator for OTP , in three days the attacker is able to pick up the second factor if he somehow knows the first one. It is not clear that the service can counter this attack without disrupting the normal work of the user. The only possible proof of work is captcha, which, in our opinion, is the last resort.
The second problem is the non-transparency of the service's judgment about the quality of the user session and deciding on the need for “pre-authentication”. Worse, the service is not interested in making this process transparent, because after all, security by obscurity actually works here. If the attacker knows on what basis the service decides on the legitimacy of the session, he can try to falsify this data. From general considerations, it can be concluded that judgment is made based on the user's authentication history, taking into account the IP address (and the autonomous system identification number identifying the provider and location based on the geobase) and browser data, such as the User Agent header and the set of cookies, flash lso and html local storage. This means that if the attacker controls the user's computer, he has the opportunity not only to steal all the necessary data, but also to use the victim's IP address. Moreover, if the decision is made on the basis of ASN, then any authentication from a public Wi-Fi in a coffee shop can lead to “poisoning” from the point of view of security (and whitening from the point of view of service) of the provider of this coffee house and, for example, the whiteing of all coffee shops in the city . We talked about the operation of the anomaly detection system , and it could be applied, but the time between the first and second stages of authentication may not be enough for a confident judgment of the anomaly. In addition, the same argument destroys the idea of "trusted" computers: an attacker can steal any information that affects the power of attorney judgment.
Finally, two-step authentication is simply inconvenient: our usability studies show that nothing annoys users more than an intermediate screen, additional button presses, and other “unimportant” actions, from his point of view.
Based on this, we decided that the authentication should be one-step and the password space should be much larger than possible within the framework of the “pure” RFC 6238.
At the same time, we wanted to preserve, as far as possible, two-factor authentication.
Multifactorial authentication is determined by assigning authentication elements (actually, they are called factors) to one of three categories:
- Factors of knowledge (these are traditional passwords, PIN codes and everything that looks like on them);
- Ownership factors (in the OTP schemes used, as a rule, this is a smartphone, but it can also be a hardware token);
- Biometric factors (the fingerprint is the most common now, although someone will remember the episode with the hero Wesley Snipes in the movie Demolition Man).
Development of our system
When we started to deal with the problem of two-factor authentication (the first pages of the corporate wiki on this issue relate to 2012, but he was discussed behind the scenes before), the first idea was to take standard authentication methods and apply them to us. We understood that it is impossible to count on the fact that millions of our users will buy a hardware token, so this option was postponed for some exotic cases (although we do not completely refuse from it, we may be able to come up with something interesting). The SMS method could not be massive either: it is a very unreliable delivery method (at the most crucial moment SMS may be delayed or not at all), and sending SMS costs money (and operators began to increase their price). We decided that the use of SMS is the lot of banks and other non-technological companies, and our users want to offer something more convenient. In general, the choice was small: use a smartphone and a program in it as the second factor.
This form of one-step authentication is widespread: the user remembers the pin code (the first factor), has a hardware or software (on the smartphone) hand token that generates OTP (the second factor). In the password entry field, he enters the pin code and the current OTP value.
In our opinion, the main drawback of this scheme is the same as that of two-step authentication: if we assume that the user's desktop is compromised, then a single pin-code entry leads to its disclosure and the attacker can only pick up the second factor.
We decided to go another way: the password is entirely generated from the secret, but only a part of the secret is saved in the smartphone, and a part is entered by the user each time the password is generated. Thus, the smartphone itself is a factor of ownership, and the password remains in the user's head and is a factor of knowledge.
Nonce can be either a counter or the current time. We decided to choose the current time, it allows not to be afraid of out of sync in case someone generates too many passwords and increases the counter.
So, we have a program for the smartphone, where the user enters his part of the secret, that is mixed with the stored part, the result is used as the HMAC key, which signs the current time, rounded up to 30 seconds. The output of the HMAC is in a readable form, and voila - this is the one-time password!
As already mentioned, RFC 4226 involves truncating the result of HMAC work to a maximum of 8 decimal digits. We decided that a password of this size is not suitable for one-step authentication and should be increased. At the same time, we wanted to maintain ease of use (after all, we recall, we want to make such a system that ordinary people will use, not just security geeks), so we chose truncating up to 8 Latin characters as a compromise in the current version of the system. It seems that 26 ^ 8 passwords that are valid for 30 seconds is quite acceptable, but if we are not satisfied with the security margin (or valuable tips will appear on Habré to improve this scheme), we will expand, for example, to 10 characters.
Read more about the strength of such passwords.
In fact, for caseless Latin letters, the number of options per character is 26, for large and small Latin letters plus numbers, the number of options is 26 + 26 + 10 = 62. Then
Magic, passivity, applications and next steps
In general, it was possible to dwell on this, but we wanted to make the system even more convenient. When a person has a smartphone in his hand, he does not want to enter a password from the keyboard!
Therefore, we began work on the "magic login". With this authentication method, the user launches the application on the smartphone, enters his PIN code into it and scans the QR code on the screen of his computer. If the PIN code is entered correctly, the page in the browser reloads and the user is authenticated. Magic!
How does it work?
In the QR code, the session number is sewn up, and when the application scans it, this number is transmitted to the server along with the password and username generated in the usual way. It's easy, because the smartphone is almost always online. In the layout of the page showing the QR code, JavaScript is running, waiting for the server to respond to the password check with this session. If the server responds that the password is correct, session cookies are set along with the response, and the user is considered authenticated.
It became better, but here we decided not to stop. Starting with the iPhone 5S, the TouchID fingerprint scanner appeared in Apple phones and tablets, and in iOS version 8, it is also available for third-party applications. In fact, the application does not gain access to the fingerprint, but if the fingerprint is correct, then an additional Keychain section becomes available to the application. This we have used. The second part of the secret, the one that the user entered from the keyboard in the previous script, is placed in the KeyDain protected TouchID entry. When unlocking Keychain, the two parts of the secret are mixed, and then the process works as described above.
But the user has become incredibly comfortable: he opens the application, puts his finger, scans the QR code on the screen and is authenticated in the browser on the computer! So we replaced the knowledge factor with a biometric one and, from the user's point of view, completely abandoned passwords. We are sure that for ordinary people such a scheme will seem much more convenient than manually entering two passwords.
It is possible to discuss how formally this two-factor authentication is, but in fact for successful passage it is still necessary to have a phone and have the right fingerprint, so we believe that we have completely managed to abandon the knowledge factor, replacing it with biometrics. We understand that we rely on the security of ARM TrustZone , the underlying iOS Secure Enclave , and we believe that at the moment this subsystem can be considered trusted in our threat model. Of course, we know the problems of biometric authentication: a fingerprint is not a password and it cannot be replaced in case of compromise. But, on the other hand, everyone knows that safety is inversely proportional to convenience, and the user himself has the right to choose an acceptable ratio of the one and the other.
Let me remind you that while it is beta. Now, when enabling two-factor authentication, we temporarily disable password synchronization in the Yandex Browser. This is due to the way the password database is encrypted. We have already come up with a convenient way to authenticate the browser in the case of 2FA. All other functionality of Yandex works as before.
That's what we did. It seems, it turned out well, but to judge you. We will be happy to hear feedback and recommendations, and we will continue to work on improving the security of our services: now, together with CSP , mail transport encryption and everything else , we also have two-factor authentication . Do not forget that authentication services and OTP generation applications are critical and that is why a double bonus is paid for errors found in the Bug Bounty program.
Source: https://habr.com/ru/post/249547/
All Articles