Double authentication Yandex. Enable two-factor authentication. Creating a Backup

We continue our review of authenticators for Android. Let me remind you that in the last article we studied not only famous applications for two-factor authentication - Google Authenticator and Azure Authenticator, but also a universal solution from a specialized developer - Authy 2-Factor Authentication. This is what became optimal.

Now we will talk about the domestic authenticator - “Yandex.Key”, designed to replace Google Authenticator. The application looks interesting, offers two types of authorization and its own protection. However, we will not give him positive marks in advance and will check everything thoroughly.

The second participant will be FreeOTP Authenticator, an open source program that in turn can become a standard for similar solutions. But these are just first guesses, so let’s not beat around the bush and get started.

The test equipment used was a DEXP Ursus 8EV2 3G tablet (Android 4.4.2, MT8382 processor, 4 x Cortex-A7 1.3 GHz, Mali-400 MP2 video core, 1 GB of RAM, 4,000 mAh battery, 3G module, Wi-Fi 802.11 b/g/n) and smartphone Homtom HT3 Pro (Android 5.1 Lollipop, MT6735P processor, 4 x Cortex-A53 1.0 GHz, 64-bit, Mali-T720 video core, 2 GB RAM, 3,000 mAh battery, 4G module, Wi -Fi 802.11b/g/n)

"Yandex.Key"

Acquaintance

“This is an authenticator that creates one-time passwords (OTP) for logging into Yandex, Facebook, Google, GitHub, Dropbox, VKontakte and other services that support two-factor authentication (2FA). On Yandex, you will enter the password created by “Key” instead of the regular password, and on other services, along with the regular one.”

The description on Google Play speaks for itself and there is nothing much to add, except the fact that some users prefer this application

Attention. Applications developed in Yandex require a one-time password - even correctly created application passwords will not work.

1. Login using QR code
2. Transferring Yandex.Key
3. Master password
4. How one-time passwords depend on precise time

Login to a Yandex service or application

You can enter a one-time password in any form of authorization on Yandex or in applications developed by Yandex.

Note.

You must enter the one-time password while it is displayed in the application. If there is too little time left before the update, just wait for the new password.

To get a one-time password, launch Yandex.Key and enter the PIN code that you specified when setting up two-factor authentication. The application will start generating passwords every 30 seconds.

Yandex.Key does not check the PIN code you entered and generates one-time passwords, even if you entered your PIN code incorrectly. In this case, the created passwords also turn out to be incorrect and you will not be able to log in with them. To enter the correct PIN, just exit the application and launch it again.

Features of one-time passwords:

Login using QR code

Some services (for example, the Yandex main page, Passport and Mail) allow you to log into Yandex by simply pointing the camera at the QR code. In this case, your mobile device must be connected to the Internet so that Yandex.Key can contact the authorization server.

Click on the QR code icon in your browser.

If there is no such icon in the login form, then you can only log in to this service using a password. In this case, you can log in using the QR code in the Passport, and then go to the desired service.

Enter your PIN code in Yandex.Key and click Login using QR code.

Point your device's camera at the QR code displayed in the browser.

Yandex.Key will recognize the QR code and send your login and one-time password to Yandex.Passport. If they pass the verification, you are automatically logged in to the browser. If the transmitted password is incorrect (for example, because you entered the PIN code incorrectly in Yandex.Key), the browser will display a standard message about the incorrect password.

Logging in with a Yandex account to a third-party application or website

Applications or sites that need access to your data on Yandex sometimes require you to enter a password to log into your account. In such cases, one-time passwords will not work - you need to create a separate application password for each such application.

Attention. Only one-time passwords work in Yandex applications and services. Even if you create an application password, for example, for Yandex.Disk, you will not be able to log in with it.

Transferring Yandex.Key

You can transfer the generation of one-time passwords to another device, or configure Yandex.Key on several devices at the same time. To do this, open the Access Control page and click the button Replacing the device.

Several accounts in Yandex.Key

The same Yandex.Key can be used for several accounts with one-time passwords. To add another account to the application, when setting up one-time passwords in step 3, click the icon in the application. In addition, you can add password generation to Yandex.Key for other services that support such two-factor authentication. Instructions for the most popular services are provided on the page about creating verification codes not for Yandex.

To remove an account link to Yandex.Key, press and hold the corresponding portrait in the application until a cross appears to the right of it. When you click on the cross, the account linking to Yandex.Key will be deleted.

Attention. If you delete an account for which one-time passwords are enabled, you will not be able to obtain a one-time password to log into Yandex. In this case, it will be necessary to restore access.

Fingerprint instead of PIN code

You can use your fingerprint instead of a PIN code on the following devices:

smartphones running Android 6.0 and a fingerprint scanner;

iPhone starting from model 5s;

iPad starting with the Air 2 model.

Note.

On iOS smartphones and tablets, the fingerprint can be bypassed by entering the device password. To protect against this, enable a master password or change the password to a more complex one: open the Settings app and select Touch ID & Passcode.

To use enable fingerprint verification:

Master password

To further protect your one-time passwords, create a master password: → Master Password.

With a master password you can:

make it so that instead of a fingerprint, you can only enter the Yandex.Key master password, and not the device lock code;

Backup copy of Yandex.Key data

You can create a backup copy of the Key data on the Yandex server so that you can restore it if you lose your phone or tablet with the application. The data of all accounts added to the Key at the time the copy was created is copied to the server. You cannot create more than one backup copy; each subsequent copy of data for a specific phone number replaces the previous one.

To retrieve data from a backup, you need to:

have access to the phone number that you specified when creating it;

Remember the password you set to encrypt the backup.

Attention. The backup copy contains only the logins and secrets necessary to generate one-time passwords. You must remember the PIN code that you set when you enabled one-time passwords on Yandex.

It is not yet possible to delete a backup copy from the Yandex server. It will be deleted automatically if you do not use it within a year after creation.

Creating a Backup

Select an item Create a backup in the application settings.

Enter the phone number to which the backup will be linked (for example, “71234567890” “380123456789”) and click Next.

Yandex will send a confirmation code to the entered phone number. Once you receive the code, enter it in the application.

Create a password that will encrypt the backup copy of your data. This password cannot be recovered, so make sure you don't forget or lose it.

Enter the password you created twice and click Finish. Yandex.Key will encrypt the backup copy, send it to the Yandex server and report it.

Yandex launched a two-factor authorization system and released the Yandex.Key application for logging into your account without having to remember and enter a complex password. The application is already available on Android and iOS, and logging into it on new iPhone models can be protected with a fingerprint scanner.

There are several ways to log into your account via Yandex.Key, but first you need to go to the settings page yandex.ru/promo/2fa and enable two-factor authentication.

Confirm your phone number with the code received via SMS.

Install the Yandex.Key application on your smartphone or tablet.

Launch the application and scan the QR code on the Yandex website. If your mobile device does not have a camera, click “Show secret key” and enter the displayed characters in the application.

Create a PIN code and enter it on the website or app.

Enter the one-time password generated by the application on the website. This password is only valid for 30 seconds, and then a new one appears. To complete the setup, you will need to enter your permanent account password again.

These steps only need to be completed once. After activating two-factor authentication, you will need to re-authorize in Yandex websites on all devices. You can create separate passwords to access applications.

Now a button with a QR code icon will appear on the Yandex account login page.

It was a rare post on the Yandex blog, especially one related to security, without mentioning two-factor authentication. We have been thinking for a long time about how to properly strengthen the protection of user accounts, and in such a way that it can be used without all the inconveniences that include the most common implementations today. And they, alas, are inconvenient. According to some data, on many large sites the percentage of users who have enabled additional authentication means does not exceed 0.1%.

It seems that this is because the common two-factor authentication scheme is too complex and inconvenient. We tried to come up with a method that would be more convenient without losing the level of protection, and today we present its beta version.

We hope it becomes more widespread. For our part, we are ready to work on its improvement and subsequent standardization.

After enabling two-factor authentication in Passport, you will need to install the Yandex.Key application in the App Store or Google Play. QR codes have appeared in the authorization form on the Yandex main page, in Mail and in Passport. To log into your account, you need to read the QR code through the application - and that’s it. If the QR code cannot be read, for example, the smartphone camera does not work or there is no access to the Internet, the application will create a one-time password that will be valid for 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 stage is normal authentication with a login and password. If it is successful, the site checks whether it “likes” this user session or not. And, if you don’t like it, it asks the user to “re-authenticate.” There are two common methods of “pre-authentication”: sending an SMS to the phone number associated with the account and generating a second password on the smartphone. Basically, TOTP according to RFC 6238 is used to generate the second password. If the user entered the second password correctly, the session is considered fully authenticated, and if not, then the session loses the “pre-authentication” as well.

Both methods ─ sending SMS and generating a password ─ are proof of ownership of the phone 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 two-step, but also two-factor.

What seemed problematic to us in this scheme?

Let's start with the fact that the average user's computer cannot always be called a model of security: turning off Windows updates, a pirated copy of an antivirus without modern signatures, and software of dubious origin - all this does not increase the level of protection. According to our assessment, compromising a user’s computer is the most widespread method of “hijacking” accounts (and recently there was another confirmation of this), and this is what we want to protect ourselves from first of all. In the case of two-factor authentication, if you assume that the user's computer is compromised, entering a password on it compromises the password itself, which is the first factor. This means that the attacker only needs to select the second factor. In the case of common implementations of RFC 6238, the second factor is 6 decimal digits (and the maximum allowed by the specification is 8 digits). According to the bruteforce calculator for OTP, in three days an attacker is able to find the second factor if he somehow became aware of the first. It is not clear what the service can counteract this attack without disrupting the normal user experience. The only possible proof of work is captcha, which, in our opinion, is the last resort.

The second problem is the opacity of the service’s judgment about the quality of the user session and making a decision on the need for “pre-authentication”. Even worse, the service is not interested in making this process transparent, because security by obscurity actually works here. If an attacker knows on what basis the service makes a decision about the legitimacy of a session, he can try to forge this data. As a general rule, we can conclude that the judgment is made based on the user's authentication history, taking into account the IP address (and its derivatives of the autonomous system number identifying the provider and the location based on the geobase) and browser data, for example, the User Agent header and a set of cookies, flash lso and html local storage. This means that if an attacker controls a user’s computer, he can not only steal all the necessary data, but also use the victim’s IP address. Moreover, if the decision is made based on ASN, then any authentication from public Wi-Fi in a coffee shop can lead to “poisoning” from a security point of view (and whitewashing from a service point of view) of the provider of this coffee shop and, for example, whitewashing all coffee shops in the city . We talked about how an anomaly detection system works, and it could be used, but the time between the first and second stages of authentication may not be enough to confidently judge an anomaly. Moreover, the same argument destroys the idea of ​​"trusted" computers: an attacker can steal any information that influences the trust judgment.

Finally, two-step authentication is simply inconvenient: our usability research shows that nothing irritates users more than an intermediary screen, additional button clicks and other “unimportant” actions from their point of view.
Based on this, we decided that authentication should be one-step and the password space should be much larger than is possible within the framework of “pure” RFC 6238.
At the same time, we wanted to preserve two-factor authentication as much as possible.

Multifactor authentication is defined by assigning authentication elements (actually, 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 OTP schemes used, this is usually a smartphone, but can also be a hardware token);
3. Biometric factors (fingerprint is the most common now, although someone will remember the episode with Wesley Snipes’ character in the film Demolition Man).

Development of our system

When we started working on the problem of two-factor authentication (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 to us. We understood that we couldn’t count on millions of our users to buy a hardware token, so we postponed this option for some exotic cases (although we are not completely abandoning it, perhaps we will be able to come up with something interesting). The SMS method also could not be widespread: it is a very unreliable delivery method (at the most crucial moment, the SMS may be delayed or not arrive at all), and sending SMS costs money (and operators have begun to increase their price). We decided that the use of SMS is for banks and other low-tech companies, and we want to offer our users something more convenient. In general, the choice was small: use the smartphone and the program in it as the second factor.

This form of one-step authentication is widespread: the user remembers the PIN code (the first factor), and has a hardware or software (in a smartphone) token that generates an OTP (the second factor). In the password input field, he enters the PIN code and the current OTP value.

In our opinion, the main disadvantage of this scheme is the same as that of two-step authentication: if we assume that the user’s desktop is compromised, then entering the PIN code once will lead to its disclosure and the attacker can only find the second factor.

We decided to go a different route: the entire password is 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.

The 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 desynchronization in case 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, it is mixed with the stored part, the result is used as an HMAC key, which is used to sign the current time, rounded to 30 seconds. The HMAC output is converted to readable form, and voila ─ here is the one-time password!

As stated earlier, RFC 4226 specifies that the HMAC result be truncated 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, remember, we want to make a system that will be used by ordinary people, and not just security geeks), so as a compromise in the current version of the system, we chose to truncate the Latin alphabet to 8 characters. It seems that 26^8 passwords valid for 30 seconds are quite acceptable, but if the security margin does not suit us (or valuable tips on how to improve this scheme appear on Habré), we will expand, for example, to 10 characters.

Learn more about the strength of such passwords

In fact, for case-insensitive 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 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 will definitely be enough for 30 seconds. If we talk about an 8-character password made of Latin letters, then its strength is log 62 (26 8) ≈ 6.3, that is, a little more than a 6-character password made of uppercase, lowercase letters and numbers. We think this is still acceptable for a 30 second window.

Magic, passwordlessness, applications and next steps

In general, we could have stopped there, but we wanted to make the system even more convenient. When a person has a smartphone in his hand, he doesn’t want to enter the password from the keyboard!

That's why we started working on the “magic login”. With this authentication method, the user launches the application on his smartphone, enters his PIN code into it and scans the QR code on his computer screen. If the PIN code is entered correctly, the page in the browser is reloaded and the user is authenticated. Magic!

How does it work?

The session number is embedded in the QR code, and when the application scans it, this number is transmitted to the server along with the password and username generated in the usual way. This is not difficult, because the smartphone is almost always online. In the layout of the page showing the QR code, JavaScript is running, waiting for a response from the server to check the password for 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 got better, but we decided not to stop here either. Starting with the iPhone 5S, Apple phones and tablets introduced the TouchID fingerprint scanner, and in iOS version 8, third-party applications can also use it. In reality, the application does not gain access to the fingerprint, but if the fingerprint is correct, then the additional Keychain section becomes available to the application. This is what we took advantage of. The second part of the secret is placed in the TouchID-protected Keychain record, the one that the user entered from the keyboard in the previous scenario. When unlocking the Keychain, the two parts of the secret are mixed, and then the process works as described above.

But it has become incredibly convenient for the user: he opens the application, places his finger, scans the QR code on the screen and finds himself authenticated in the browser on his 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 this scheme much more convenient than manually entering two passwords.

It's debatable how technically two-factor authentication this is, but in reality you still need to have a phone and have the correct fingerprint to successfully complete it, so we believe that we have been quite successful in eliminating the knowledge factor, replacing it with biometrics. We understand that we rely on the security of the ARM TrustZone that underlies iOS Secure Enclave, and we believe that this subsystem can currently be considered trusted within our threat model. Of course, we are aware of the problems with biometric authentication: a fingerprint is not a password and cannot be replaced if compromised. 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 still a beta. Now, when two-factor authentication is enabled, we temporarily disable password synchronization in Yandex Browser. This is due to the way the password database is encrypted. We are already coming up with a convenient way to authenticate the Browser in the case of 2FA. All other Yandex functionality works as before.

This is what we got. It seems to have turned out well, but you be the judge. We will be glad to hear your feedback and recommendations, and we will continue to work on improving the security of our services: now, along with CSP, encryption of mail transport and everything else, we now have two-factor authentication. Do not forget that authentication services and OTP generation applications are critical and therefore a double bonus is paid for errors found in them as part of the Bug Bounty program.

Tags: Add tags