Easy two-factor authentication

    A rare Yandex blog post, and especially regarding security, did without mentioning two - factor authentication. We thought for a long time 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 percentage of users who include additional authentication tools does not exceed 0.1%.

    This seems to be because the common two-factor authentication scheme is too complicated and inconvenient. We tried to come up with a way that would be more convenient without losing the level of protection, and today we are presenting its beta version.

    We hope it will become 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, QR codes appeared on the Yandex home page, in the Mail and Passport. To enter the account, you need to read the QR code through the application - and that’s all. If you cannot read the QR code, for example, the smartphone’s camera does not work or there is no access to the Internet, the application will create a one-time password that will last 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-stage. The first step is regular authentication with a username and password. If it was successful, the site checks whether he likes this user session or not. And, if you don’t like it, it asks the user to “authenticate”. There are two common methods of “authentication”: sending an SMS to a phone number tied to an account and generating a second password on a smartphone. Basically, TOTP is used to generate the second password according to RFC 6238. If the user has entered the second password correctly, the session is considered fully authenticated, and if not, then the session loses the “preliminary” authentication.

    Both methods ─ sending SMS and generating a password ─ proof of possession of the phone and therefore are a factor of availability. The password entered in the first stage is a knowledge factor. Therefore, such an authentication scheme is not only two-step, but also two-factor.

    What seemed to us problematic in this scheme?

    To begin with, the average user's computer cannot always be called a security model: here you can turn 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. In our opinion, compromising a user's computer is the most widespread way to “hijack” accounts (and recently there was one more confirmation of this), in the first place, and I want to defend myself. 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. So, the attacker only needs to pick up 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 OTP calculator , in three days an attacker is able to pick up the second factor if he somehow knows the first. It is not clear that the service can counter this attack without disturbing the normal operation of the user. The only possible proof of work ─ captcha, which, in our opinion, is the last resort.

    The second problem is the opacity of the service’s judgment on the quality of the user session and the decision on the need for “additional authentication”. Worse, the service is not interested in making this process transparent, because security by obscurity actually works here. If the attacker knows what the service decides on the legitimacy of the session on, he can try to fake this data. From general considerations, we can conclude that the judgment is made on the basis of the user's authentication history, taking into account the IP address (and its derivative autonomous system identifying numbers of the provider, and the location based on the geobase) and browser data, for example, the User Agent header and cookie set, flash lso and html local storage. This means that if an attacker controls a user's computer, then he can not only steal all the necessary data, but also use the victim’s IP address. Moreover, if the decision is made on the basis of ASN, then any authentication from public Wi-Fi in the coffee house can lead to “poisoning” from the point of view of security (and whitewashing from the point of view of service) of the provider of this coffee house and, for example, the whitewashing of all coffee houses in the city . We talked about workanomaly detection system , and it could be applied, but the time between the first and second stage of authentication may not be enough for a reliable judgment about the anomaly. In addition, this same argument destroys the idea of ​​“trusted” computers: an attacker can steal any information that affects the proxy judgment.

    Finally, two-step authentication is simply inconvenient: our usability studies show that nothing irritates users like an intermediate screen, additional button presses and other “unimportant” actions, from his point of view.
    Based on this, we decided that authentication should be one-step and that the password space should be much larger than could be done in the framework of a “clean” RFC 6238.
    At the same time, we wanted to preserve the two-factor authentication whenever possible.

    The multifactorial nature of authentication is determined by assigning authentication elements (in fact, they are called factors) to one of three categories:
    1. Knowledge factors (these are traditional passwords, pin codes and everything that looks like them);
    2. Ownership factors (in the OTP schemes used, this is usually a smartphone, but there may also be a hardware token);
    3. Biometric factors (a fingerprint is the most common now, although someone will recall the episode with Wesley Snipes's hero in the movie Demolition Man).

    Development of our system

    When we started dealing with the two-factor authentication problem (the first pages of the corporate wiki on this issue date back to 2012, but it was discussed behind the scenes before), the first idea was to take standard authentication methods and apply them with us. We understood that millions of our users could not be expected to buy a hardware token, so this option was postponed for some exotic cases (although we do not completely refuse it, we may be able to come up with something interesting). The SMS method also could not be mass: it is a very unreliable method of delivery (at the crucial moment SMS may be delayed or not reach at all), and sending SMS costs money (and operators began to increase their price). We decided that the use of SMS is the destiny of banks and other low-tech companies, and our users would like to offer something more convenient. In general, the choice was small: to use a smartphone and the program in it as a second factor.

    This form of one-step authentication is widespread: the user remembers the PIN code (the first factor), has a hardware or software (in the smartphone) 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 entry of the PIN code leads to its disclosure and the attacker can only pick up the second factor.

    We decided to go the other way: the password is entirely generated from the secret, but only part of the secret is stored in the smartphone, and 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, this allows us not to be afraid of out of sync if someone generates too many passwords and increases the counter.

    So, we have a program for a smartphone where the user enters his part of the secret, that is mixed with the stored part, the result is used as an HMAC keywhich marks the current time, rounded to 30 seconds. The output of the HMAC is reduced to a readable form, and voila ─ here’s the one-time password!

    As already mentioned, RFC 4226 suggests truncating the result of HMAC to a maximum of 8 decimal digits. We decided that a password of this size is unsuitable for one-step authentication and should be increased. At the same time, we wanted to maintain ease of use (because, recall, we want to create a system that ordinary people will use, and not just security geeks), so as a compromise in the current version of the system, we chose truncation to 8 characters of the Latin alphabet. It seems that 26 ^ 8 passwords valid for 30 seconds is quite acceptable, but if the security margin does not suit us (or valuable tips appear on the Habré how to improve this scheme), we will expand, for example, up to 10 characters.

    Read more about the strength of such passwords

    In fact, for case-insensitive Latin letters, the number of variants per character is 26, for large and small Latin letters plus numbers, the number of variants is 26 + 26 + 10 = 62. Then log 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 definitely enough for 30 seconds. If we talk about an 8-character password from Latin letters, then its durability log 62 (26 8 ) ≈ 6.3 , that is, a little more than a 6-character password from capital, small letters and numbers. We believe that this is still acceptable for a window of 30 seconds.

    Magic, passwordless, applications and next steps

    In general, we could stop at this, but we wanted to make the system even more convenient. When a person has a smartphone in his hand, I don’t feel like entering a password from the keyboard!

    Therefore, we began work on a “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?

    The session number is stored in the QR code, and when the application scans it, this number is transmitted to the server along with the password and user name worked out in the usual way. This is not difficult, because the smartphone is almost always online. JavaScript is working in the layout of the page showing the QR code, waiting on the server side to respond to the password check with this session. If the server replies 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 has appeared on Apple phones and tablets, and in iOS version 8, third-party applications are also available. In fact, the application does not get access to the fingerprint, but if the fingerprint is correct, then the application becomes available an additional section Keychain. This is what we took advantage of. The second part of the secret, the one that the user entered from the keyboard in the previous scenario, is placed in the Keychain protected TouchID record. When Keychain is unlocked, the two parts of the secret are mixed, and then the process works as described above.

    But the user was 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 ordinary people will find such a scheme much more convenient than manually entering two passwords.

    One can debate how formally such two-factor authentication is, but in order to pass it successfully it is still necessary to have a telephone and have the correct 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 the ARM TrustZone underlying iOS Secure Enclave, and we believe that at the moment this subsystem can be considered trusted in the framework of our threat model. Of course, we are aware of 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 security is inversely proportional to convenience, and the user himself has the right to choose the ratio of one and the other that is acceptable to him.

    Let me remind you that this is beta so far. Now, when you enable two-factor authentication, we temporarily turn off password synchronization in Yandex.Browser. This is due to how the encryption of the password database is arranged. We are already coming up with a convenient way to authenticate the Browser in the case of 2FA. All other Yandex functionality works in the same mode.

    That's what we got. It seems to have worked out well, but it's up to you to judge. We will be glad to hear feedback and recommendations, and we ourselves will continue to work to improve the security of our services: now, along with CSP , encryption of mail transport and everything else , we also have two-factor authentication . Do not forget that authentication services and OTP generation applications are critical and therefore a double premium is paid for errors detected in them as part of the Bug Bounty program .

    Also popular now: