To date, the idea of ​​avoiding passwords and traditional authentication methods on web resources is rising more and more, and the giants of the IT industry, such as Google, Paypal and other members of the FIDO alliance , have been concerned about this. As part of the research conducted by Google employees, ways to improve authentication methods have been proposed, as well as a draft of the TLS extension standard, which eliminates the use of cookies.

In this article I will talk about the problems of traditional authentication schemes, about pitfalls with the introduction of two-stage authentication and consider the proposed standard TLS extension. The text of the article will be useful to web developers who plan to embed two-step authentication.

When discussing methods of strong authentication it is often a question that all the proposed methods are too complicated or inconvenient for the user. In this case, two complementary solutions can be proposed:

• Separation of accounts by their significance.
• Using user-transparent authentication

Distinguishing accounts

Obviously, not all accounts require strong authentication. Google offers to divide them into the following types:

• One-time accounts on services where the user does not plan to return anymore. Such services do not need strict authentication controls.
• Typical accounts that the user values, but losing them will not cause material or reputational losses.
• Public accounts: Twitter or a blog with a large number of subscribers, as well as a database of online stores with credit card data
• Critical accounts: primary postal addresses or online banking accounts.

It is obvious that the need for strong authentication has the last two types of accounts, and it is worth noting that over time, classes of accounts can flow from one to another.
')

Typical threats

For any account characterized by the following banal and not very threats:

• Phishing, which if cleverly disguised, will not save even two-factor confirmation codes
• User reuse of passwords (or even the same) for multiple accounts
• Entering the correct password by the user in the wrong field or to another account. This threat is not so obvious, but there is a place to be: sometimes I myself began to drive in the password in the login form.
• Social engineering focused on password recovery techniques.
• Infection of the user's computer with viruses.

Partially, these threats can be avoided by using the password manager, but this requires the installation of separate programs and is poorly compatible with the abundance of user devices on different operating systems.

Users usually do not have to do with security, their types of account and possible threats. As practice shows, any changes related to security are perceived by people with bayonets. Therefore, in addition to developing inconspicuous authentication methods, it is also necessary to think about the transparency of the way to transition to new mechanisms.

New ways of old authentication

Delegation of device authentication

Now people have more and more new pieces of hardware that have access to the network and from which users perform authentication on various services. At the same time, the devices may in one way or another store user data for later use.

Suppose now that a user can allow a device to access his accounts one time, thus delegating the right to authenticate to his device. To some extent, such a scheme has already been implemented in modern mobile OS. It is required to review the authentication caching process by adding a description of the following things:

• Directly delegate access using multifactor authentication, if necessary.
• The label must uniquely identify the user's device and be invalid when used from another device. This will allow the server to understand which particular device the user is currently logged on from and also protects against possible theft of the access label.
• "Lifetime" access tags. Ideally, if the label is unique, then access should be allowed until the user decides to revoke it.
• The process of revoking access in case of loss of the device. If the device is lost, you only need to disable the access label and you will not need to change the password itself.
• Protect the device itself with a PIN code and communicate the need for this to users.
• Identifying transactions that require confirmation by the user (such as changing a password, deleting an account, or cash transactions

Subsequently, when a user has several authenticated devices at his disposal, he will not have to enter passwords at all, since it will be possible to configure the delegation of rights between individual devices. This suggests that primary authentication should be performed using several factors and cryptographically strong algorithms.

Thoughts of multifactor authentication

The technique of two- and more-factor authentication has long been used in various areas of information security, and now many popular web services include the possibility of multi-factor authentication. For example, after Google and Amazon, Twitter, Dropbox and LinkedIn were also involved in the game. At the same time, most services use the OTP mechanism as the second factor. Besides the fact that this method is not very convenient (each time you have to wait for an SMS, either launch a special application, or generate a password on an OTP token and then enter it with handles), OTP has a number of vulnerabilities - the possibility of phishing and, moreover, the need to store on server secret OTP generator in the clear. The bitter experience of well-known and not-so companies finally taught us to use strong password hashing, after which the need to keep the OTP secret in the open form looks strange, to say the least. To ensure the secure storage of authentication data on the server, it is necessary to use asymmetric cryptographic algorithms. I will consider these questions further in the text of the article, but for now I offer the reader the main difficulties that arise when developing a multifactor authentication system.

When implementing even the simplest two-step authentication, you need to consider:

• the behavior of the application if the user is located outside the cellular network (for example, on vacation)
• user recovery process of their account
• the process of changing the device / mobile number and revoking access labels

In addition to the general organization of the account access scheme, it is important to consider that many applications will not be able to immediately switch to a new authentication procedure. In this case, it is convenient to implement authentication in applications based on Web-forms, as now Google does in all its mobile programs. This method will allow developers to abstract from different authentication APIs and treat the whole process as one black box, at the output of which the program will receive an access label.

Since two-factor authentication should be the most transparent and unobtrusive for the user, it is obvious that in typical accounts one cannot fully switch to it. Thus, it is necessary to find a compromise that will not burden the user and ensure the security of the account. Google's research has shown that the requirement to re-authenticate once a month is too intrusive and at the same time does not protect against the threat of losing the device. The golden mean in this case is the requirement of two-factor authentication when the user first logs into the system, after which a “super-cookie” is recorded in the browser or on the device, which authorizes the specific device in the future. Moreover, if the user wants it, he can limit the life of the cookie by the browser session.

As an unexpected minus of two-step authentication, you can highlight its use by attackers to intercept account management: after an attacker has gained access to an account with two-step authentication disabled, he can configure it using his phone number, thus complicating the account recovery process.

As intermediate output

Overall, modern two-step authentication methods (for example, OTP over SMS) help protect against threats of password reuse and leakage of password hashes (yeah, and sometimes open passwords) from the server, but still prove ineffective against carefully crafted phishing or a targeted attack involving the theft of the phone itself. Thus, it is necessary to consider a mechanism that will not have OTP vulnerabilities, and will also require fewer actions from the user during authentication.

Closer to the gland and implementation

Above, I talked about the need to use public key cryptography to protect against phishing and against data theft from the server. At the same time, it is rational to use additional devices in the form of USB tokens for storing key information. As practice shows, the transition to such technologies should be as simple as possible, therefore it is necessary to establish the following requirements:

1. The technology should not require the installation of additional software beyond the browser and its extensions
2. One device should be enough to store data to the set of websites on which the user is registered
3. Registration and authentication protocols should be open and should not rely on third-party services. It is very important to note here that no other parties should enter into the relationship between the user and the site, because the user trusts the site (this is also facilitated by SSL).

The browser (+ plugin) should provide the site with two APIs: for registering new users and for authentication. When creating a new account, the service calls the registration API, as a result of which a new key pair is generated on the device, the public key of which is stored on the server. Subsequently, this key will be used to confirm the user's identity as follows: using the authentication API, the server sends a request to the user, who signs it and returns it. This authentication scheme is implemented in our products Rutoken Web and Rutoken Plugin .

It is worth noting that the experience of Chrome browser developers shows that the use of certificates for simple authentication is not appropriate. In this regard, Google proposes to create an extension to the TLS protocol, which will implement the authentication scheme described above.

TLS ChannelID extension

This extension is described in the IETF draft and offers a mechanism for extending the TLS protocol, which allows you to get rid of the transfer of authentication tokens (English, bearer token), such as HTTP cookies or OAuth tokens.

The owner of such a token (somehow obtained earlier) can access the resource, regardless of who has the token and on what channel it is transmitted. Thus, an attacker who has taken possession of the authentication token can, without any problems, log in under the face of another user.

The draft standard describes a TLS extension, with which you can create a long-term channel between the client and the server, which will be maintained between different HTTP requests and TLS sessions if these connections originate from the same client device.

The essence of this method is that after the initial authentication, instead of a cookie, a key pair is generated on the client device, the public key of which is stored on the server. Later, during the establishment of a TLS connection (TLS handshake), the client proves to the server that he owns the private key, and the public key is the channel identifier (Channel ID). This method is better than using cookies for several reasons:

• The private key never leaves the client device, so the attacker will not be able to intercept the secret from the channel
• All cryptographic operations can be performed on a separate device, which protects the private key from theft directly from the client

TLS handshake process description

When establishing a connection, the client can add the extension “channel_id (0x754F)” to the ClientHello message. If the server supports this extension, it can signal this to the client in a ServerHello message.

After receiving the extended ServerHello from the server, the client should check the strength of the selected encryption algorithm and respond with an “EncryptedExtensions” message after “ChangeCipherSpec” and before “Finished”. This message indicates the public key parameters and the signature value in the following format:

struct { opaque x[32]; opaque y[32]; opaque r[32]; opaque s[32]; } ChannelIDExtension; 

Here, x, y, r, and s are 32-byte big-endian numbers. The x and y fields contain the affinity coordinates of the P-256 elliptic curve, and the r and s fields contain the ECDSA signature with the corresponding private key. The general TLS handshake scheme is shown in the figure below. Green highlighted modifications compared to the standard.

As a conclusion

Since the standard is still in development, it is difficult to draw any rigorous conclusions, but at a minimum, we can single out the trends that Google sees in the field of authentication development. First, it is obvious that traditional password authentication should be complemented by other means. Secondly, with the emergence of a large number of device users, it is necessary to develop a reliable method of authenticating these devices. And thirdly, it is possible to distinguish the trend of “shift” of account security levels: if earlier two-factor authentication was used mainly in RBS services, now it has moved into the sphere of public accounts. From this it can also be concluded that the RBS services themselves now require more stringent authentication methods than OTP.