Rare blog post Yandex, especially regarding security, without mentioning two-factor authentication. We thought long and hard how to strengthen the protection of user accounts, and even so that it could be used without all the inconveniences, which include the most common current implementation. But, alas, they are inconvenient. According to some reports, many major sites share of users, including 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 have tried to think of a way that would be more convenient without losing the level of protection, and today we present its beta version.
Hopefully he will get more widespread. For our part we are ready to work on improving it and subsequent standardization.
After you enable two-factor authentication in the Data Sheet you will need to install the application Yandeks.Klyuch in App Store or Google Play. In the login form on the main page of Yandex, a mail and passport will be QR-code. To enter the account must be read QR-code through the app - and all. If we assume QR-code does not work, does not work like camera or smartphone does not have access to the internet, the application will create a one-time password, which will operate a total of 30 seconds.
I'll tell you why we decided not to use such "standard" mechanisms such as RFC 6238 and RFC 4226. How do the two-factor authentication schemes common? They are two-stage. The first stage ─ common authentication username and password. If it succeeds, the site checks "like" him this user session or not. And if the "do not like", asks the user "doautentifitsirovatsya." Common methods "doautentifikatsii" two: sending an SMS to your account tied to a phone number and password to the second generation smartphone. Mainly for generating a second password is used for TOTP RFC 6238. If the user has entered the second password is correct, the session is considered fully authenticated, and if not, the session loses and "provisional" authentication.
Both methods ─ SMS sending and password generation ─ proof of owning the phone and are therefore factor presence. The password entered in the first stage, ─ factor knowledge. Therefore, this authentication scheme ─ not only the two-stage, but also two-factor.
What struck us as problematic in this scheme?
Let's start with the fact that the computer the average user can not always be called a model of security: there are updates off Windows, and a pirate copy without modern antivirus signatures and software of dubious origin ─ all of this does not increase the level of protection. We estimate that compromise the user's computer ─ the most popular way of "stealing" accounts (and recently that was another confirmation) from it in the first place and wants to protect. In the case of a two-step authentication, if we assume that the user's computer is compromised, the password on it compromises the password itself, which is the first factor. This means that an attacker only needs to pick up the second factor. In the case of common implementations of RFC 6238 ─ second factor is 6 decimal digits (and the maximum prescribed specification, ─ 8 digits). According to the calculator bruteforce for OTP, three days attacker is able to pick up the second factor, if it somehow came to be known first. Not clear that the service can counter this attack without disturbing the normal operation of the user. The only possible proof of work ─ CAPTCHA that, in our view, is the last resort.
The second problem ─ opacity judgments about the quality of the service user's session and decide on the need to "doautentifikatsii." To make matters worse, the service is not interested in what would make the process transparent, ─ because here actually works security by obscurity. If an attacker knows, based on which service decides on the legitimacy of the session, it may attempt to forge the data. From general considerations it can be concluded that the judgment is based on the history of user authentication based on IP-addresses (and its derivatives autonomous system number that identifies the provider, and location-based geodatabase) and browser data, such as 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, it has the ability to not only steal all the necessary data, but also to take advantage of IP-address of the victim. Moreover, if the decision is made on the basis of ASN, then any authentication of public Wi-Fi at a coffee shop could lead to "poison" in terms of security (and whitewash in terms of service) provider of coffee, for example, whitewash all coffee in town . We talked about the system anomaly detection, and it can be applied, but the time between the first and second stage of authentication may not be sufficient for certain judgments about the anomaly. In addition, this same argument destroys the idea of "trusted" computers: an attacker can steal any information that affects the judgment of the proxy.
Finally, a two-step authentication simply uncomfortable: our usability-studies show that there is nothing that irritates users as an intermediate screen, additional button press and other "unimportant", from his point of view action.
For this reason, we decided that authentication should be single-stage space and passwords should be much more than can be done within the framework of "pure» RFC 6238.
At the same time we would like if possible to save two-factor authentication.
Multifactor authentication to determine whether a hedged items authentication (in fact, they are called factors) into one of three categories:
Factors knowledge (that traditional passwords, PIN codes, and all that like them);
Factors ownership (used in the OTP-schemes, as a rule, this is a smartphone, but it could be a hardware token);
Biometric factors (fingerprint ─ the most common now, although someone will remember the episode with the hero Wesley Snipes in the movie Demolition Man).
The development of our system
When we began to address the problem of two-factor authentication (the first page of the corporate wiki on this issue relate to 2012, but behind the scenes it was discussed earlier), the first idea was to take the standard authentication methods and apply them in our country. We understand that you can not count on the fact that millions of our customers buy hardware token, so this option is postponed to some exotic cases (although we totally do not refuse him, maybe we can come up with something interesting). Way with SMS too, could not be massive: it is a very unreliable way of delivery (at the crucial moment SMS may be delayed or does not reach) and sending SMS costs money (and operators have begun to increase their prices). We decided that the use of SMS ─ inheritance banks and other non-technological companies, our customers want to offer something more comfortable. In general, there was little choice: use your smartphone and program it as a second factor.
Widespread this form of one-step authentication: the user to remember the PIN code (the first factor), has on hand a hardware or software (smartphone) token generated OTP (second factor). In the password field, he enters the PIN and the current value of the OTP.
It seems that this is because the common two-factor authentication scheme is too complicated and inconvenient. We have tried to think of a way that would be more convenient without losing the level of protection, and today we present its beta version.
Hopefully he will get more widespread. For our part we are ready to work on improving it and subsequent standardization.
After you enable two-factor authentication in the Data Sheet you will need to install the application Yandeks.Klyuch in App Store or Google Play. In the login form on the main page of Yandex, a mail and passport will be QR-code. To enter the account must be read QR-code through the app - and all. If we assume QR-code does not work, does not work like camera or smartphone does not have access to the internet, the application will create a one-time password, which will operate a total of 30 seconds.
I'll tell you why we decided not to use such "standard" mechanisms such as RFC 6238 and RFC 4226. How do the two-factor authentication schemes common? They are two-stage. The first stage ─ common authentication username and password. If it succeeds, the site checks "like" him this user session or not. And if the "do not like", asks the user "doautentifitsirovatsya." Common methods "doautentifikatsii" two: sending an SMS to your account tied to a phone number and password to the second generation smartphone. Mainly for generating a second password is used for TOTP RFC 6238. If the user has entered the second password is correct, the session is considered fully authenticated, and if not, the session loses and "provisional" authentication.
Both methods ─ SMS sending and password generation ─ proof of owning the phone and are therefore factor presence. The password entered in the first stage, ─ factor knowledge. Therefore, this authentication scheme ─ not only the two-stage, but also two-factor.
What struck us as problematic in this scheme?
Let's start with the fact that the computer the average user can not always be called a model of security: there are updates off Windows, and a pirate copy without modern antivirus signatures and software of dubious origin ─ all of this does not increase the level of protection. We estimate that compromise the user's computer ─ the most popular way of "stealing" accounts (and recently that was another confirmation) from it in the first place and wants to protect. In the case of a two-step authentication, if we assume that the user's computer is compromised, the password on it compromises the password itself, which is the first factor. This means that an attacker only needs to pick up the second factor. In the case of common implementations of RFC 6238 ─ second factor is 6 decimal digits (and the maximum prescribed specification, ─ 8 digits). According to the calculator bruteforce for OTP, three days attacker is able to pick up the second factor, if it somehow came to be known first. Not clear that the service can counter this attack without disturbing the normal operation of the user. The only possible proof of work ─ CAPTCHA that, in our view, is the last resort.
The second problem ─ opacity judgments about the quality of the service user's session and decide on the need to "doautentifikatsii." To make matters worse, the service is not interested in what would make the process transparent, ─ because here actually works security by obscurity. If an attacker knows, based on which service decides on the legitimacy of the session, it may attempt to forge the data. From general considerations it can be concluded that the judgment is based on the history of user authentication based on IP-addresses (and its derivatives autonomous system number that identifies the provider, and location-based geodatabase) and browser data, such as 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, it has the ability to not only steal all the necessary data, but also to take advantage of IP-address of the victim. Moreover, if the decision is made on the basis of ASN, then any authentication of public Wi-Fi at a coffee shop could lead to "poison" in terms of security (and whitewash in terms of service) provider of coffee, for example, whitewash all coffee in town . We talked about the system anomaly detection, and it can be applied, but the time between the first and second stage of authentication may not be sufficient for certain judgments about the anomaly. In addition, this same argument destroys the idea of "trusted" computers: an attacker can steal any information that affects the judgment of the proxy.
Finally, a two-step authentication simply uncomfortable: our usability-studies show that there is nothing that irritates users as an intermediate screen, additional button press and other "unimportant", from his point of view action.
For this reason, we decided that authentication should be single-stage space and passwords should be much more than can be done within the framework of "pure» RFC 6238.
At the same time we would like if possible to save two-factor authentication.
Multifactor authentication to determine whether a hedged items authentication (in fact, they are called factors) into one of three categories:
Factors knowledge (that traditional passwords, PIN codes, and all that like them);
Factors ownership (used in the OTP-schemes, as a rule, this is a smartphone, but it could be a hardware token);
Biometric factors (fingerprint ─ the most common now, although someone will remember the episode with the hero Wesley Snipes in the movie Demolition Man).
The development of our system
When we began to address the problem of two-factor authentication (the first page of the corporate wiki on this issue relate to 2012, but behind the scenes it was discussed earlier), the first idea was to take the standard authentication methods and apply them in our country. We understand that you can not count on the fact that millions of our customers buy hardware token, so this option is postponed to some exotic cases (although we totally do not refuse him, maybe we can come up with something interesting). Way with SMS too, could not be massive: it is a very unreliable way of delivery (at the crucial moment SMS may be delayed or does not reach) and sending SMS costs money (and operators have begun to increase their prices). We decided that the use of SMS ─ inheritance banks and other non-technological companies, our customers want to offer something more comfortable. In general, there was little choice: use your smartphone and program it as a second factor.
Widespread this form of one-step authentication: the user to remember the PIN code (the first factor), has on hand a hardware or software (smartphone) token generated OTP (second factor). In the password field, he enters the PIN and the current value of the OTP.
No comments:
Post a Comment