It's no secret that today there is a big problem with Internet security. Users use easy passwords and reuse them on other resources. Password managers are still new to the average user, and your grandmother is unlikely to be forced to use random one-time passwords with high entropy. Life is decay and pain ...

At the dawn of Web2.0, we began to realize that passwords were not enough and invented two-factor authentication or 2FA.

What are 2FA solutions today?

• SMS - one-time passwords sent via SMS.

  
  

• OTP (TOTP / HOTP) - one-time passwords generated based on master keys. Examples: Google Authenticator, Yubikey, bank OTP tokens.

  
  
• Cryptographic Tokens are hardware for multifactor user authentication. Examples: RSA SecureID, Rutoken.

With a large choice of solutions, users still have accounts taken away. So why the existing technology did not solve the problem?

There are many reasons:

• Phishing - almost all of these solutions are vulnerable to MITM (man in the middle) attacks, and therefore phishing. What will stop a user who has already entered his login and password from entering a one-time password?

  
  

• Security - in this case I will speak about SMS. SMS is currently the most popular 2FA solution on the market. Stories about the re-release of a SIM card happened not only in Russia, but also in the USA , South Africa , Great Britain and other countries. Almost all providers provide the ability to restore SIM cards, and no one has yet canceled social engineering methods.

  
  

• Cost - if you are a Swiss bank, and your client stores seven-digit amounts of foreign currency, then RSA tokens are a meager price to ensure the security of your clients' accounts. And if you are Twitter or Facebook, then it is simply impossible to issue expensive tokens to each user. SMS also costs money, and if you keep an amateur anime forum about discussions about how to patch KDE under FreeBSD, then you can hardly afford an SMS.

  
  

• Compatibility - no one likes messing around with drivers, and this is one of the reasons that RSA and Rutoken still haven't conquered the world.

  
  
• Ease of use - enter one-time passwords is a hassle. Unlock the screen, open messages, read the code, make a mistake, burn the phone and computer - this is the standard algorithm for user interaction and two-factor authentication.

This list can be continued for a long time, but I think that the thought has been conveyed. Today's solutions are not able to reliably protect the user, are difficult to use, are expensive and not universal.

FIDO U2F - Universalize the second factor

In 2013, the FIDO (Fast IDentity Online) Alliance was established in Silicon Valley to address the challenges of easy and secure authentication on the Internet. Currently, FIDO has more than three hundred associate members and thirty board members. The list of board members includes such companies as Google, Yubico, Microsoft, Visa, Mastercard, American Express, Paypal and others .

The main goals that FIDO has set itself are easy-to-use, secure, private, and standardized solutions.

At the moment, FIDO presented two standards: U2F (Universal Second Factor) - universal second factor, UAF (Universal Authentication Framework) - universal authentication framework for biometric authentication. Today we talk about U2F. If the topic is interesting, then in the future I can write an article on UAF.

U2F is an open, driverless protocol for two-factor authentication, based on challenge-response authentication using an electronic digital signature.

How it works?

U2F protocol has three levels of abstraction: User, Browser (tech. Client) and Protocol itself.

User

For the user, everything is quite simple. The user enters the username and password, inserts the U2F device, presses the button and successfully authenticates. Actually about it already earlier wrote on HabraHabr.

Browser

The algorithm for interacting with U2F on the browser side is as follows:

• The user passes the login and password verification

  
  

• The dependent party, Google for example, through the U2F JS API requests a call signature (challenge)

  
  
• The browser forwards the request to the device.

If the user has confirmed, for example, by pressing a button or otherwise, his desire to perform two-factor authentication, the device returns the call signature

• The browser transfers the signature to the dependent party.

  
  
• Dependent party verifies the signature

Protocol - or five and a half steps to secure two-factor authentication

Step One - Call-Answer

To begin with, we produce a simple call-response. The server sends us a random call. Our device signs the call and returns the signature to the server, after which the server verifies the signature.

Step Two - Phishing Protection

Sign the original URL and Channel ID

By itself, the call-response does not solve the problem of phishing, because if you log in to r n ail.ru instead of mail.ru, then your signature can still be used to log into your account. To protect against this, the browser adds to the call the URL from which the signature request was made, and the TLS channel ID, after which the dependent party verifies this data.

Step Three - Privacy or registration-dependent key pair

We generate a registration-dependent pair.

At the moment, our device signs all with one pair of keys. This creates a problem for privacy, due to the fact that the public key will be the same everywhere. For example, let's say if you were registered on the infamous AshleyMadison.com, then the attacker could link the merged public key and your other accounts and potentially cause physical and moral harm.

To keep your registration private, the dependent party sends the application ID (AppID) and seed (random number). Based on this data, the device generates a unique registration-dependent key pair. How the device generates a pair is not described in the protocol, but is completely left to the discretion of the device manufacturer. For example, each Yubikey has its own master key, which, in conjunction with the HMAC and PRNG (Pseudorandom Number Generator), generates a new pair.

https://developers.yubico.com/U2F/Protocol_details/Key_generation.html

Due to the fact that the key pair is unique for each registration, it becomes possible to use one U2F device for multiple accounts together.

Step Four - Protection from Cloning

Since U2F is only a protocol, it can have different implementations, in hardware and software. Some implementations may not be resistant to cloning. To protect against this, the U2F device has a built-in counter. Each signature and registration increases the state of the counter by one. The state of the counter is signed and returned to the dependent party. If the U2F device was tilted, then the state of the counter of the cloned device is likely to be less than the state of the counter of the original device, which will cause an error during verification.

Step Five - Key Certification

Different protocol implementations may be unsafe. To avoid this, each U2F device has a built-in party certificate that is installed for approximately every hundred thousand devices. Each signature and registration is additionally signed by a certificate, the public key of which is in the public directory.

Why is this necessary? For example, if you are a forum about kittens, then you may not be very worried about how safe your users' U2F devices are, and if you are a bank, then you may only allow devices made in hardware and only if they are certified by the FIDO Alliance.

Step Six and a Half - Bust Protection

In a situation where the user is away from his device, malicious software may attempt to attack the device using brute force or other types of attacks. To protect against this, the U2F standard requires that all implementations, in hardware and software, are activated by the user. The user is obliged to confirm his decision on two-factor authentication. This action can be simply pressing a button, entering a pin-code, taking a fingerprint, or another.

Services with multiple entry points

Take for example Gmail.

You can sign in to Gmail from both the web and mobile interfaces. How can I authorize a user with an android application, if the AppID of our application and the AppID of the service differ?

For this there are facets.

Facets is a JSON file with a list of all IDs that are allowed to perform authentication for the selected service. For an example, here are the Google facets:

{ "trustedFacets": [{ "version": { "major": 1, "minor" : 0 }, "ids": [ "https://accounts.google.com", "https://myaccount.google.com", "https://security.google.com", "android:apk-key-hash:FD18FA800DD00C0D9D7724328B6...", "android:apk-key-hash:Rj6gA3QDA2ddyQyi21JXly6gw9...", "ios:bundle-id:com.google.SecurityKey.dogfood" ] }] } 

Facets must be in the same domain space as AppID. For example, if our AppID is https://example.com/facets.json , then https: //**security***.example**.com will be tested, and https: //security.example .net ** no .

For mobile applications, facets have a URI scheme of the form “OS: TYPE: ID”. For android calculates SHA-1 signing certificate apk. For IOS, this is the bundle ID.

Facets are required to be heard on HTTPS!

Specs

At the moment, specifications are ready for USB, NFC and Bluetooth LE.

Browser Support

Chrome supports U2F out of the box since early 2015. U2F support in Firefox is currently in active development. Microsoft announced U2F support for both Windows 10 and Edge as part of the FIDO2.0 stack, and it is already available in Insider Build.

Who is using?

Google, Github, Wordpress, Dropbox, Evernote. The UK government has recently introduced support for U2F for its government sites, which delivers a lot.

What to consider when switching to U2F?

• HTTPS is OBLIGATED — it’s not enough that if you don’t provide HTTPS to your users, then you don’t care about their security, and U2F will be of little interest to you. Firefox, Chrome, and Edge require an HTTPS connection to use the U2F API.

  
  

• Try TLS SessionID.

  
  
• U2F is the second factor. Do not be like banks. Do not use 2FA as a major factor.

Summing up

U2F is a well thought out, strong, open and standardized technology. It was successfully tested by Google on its employees, who use U2F at the moment as the main two-factor authentication method.

U2F is just a protocol, which entails creating a huge market for solutions based on it. From crypto keys with a secure element, JavaCard implementations, to mobile applications and biometric-protected U2F devices, U2F gives you the freedom to use your imagination where it can be used.

Notes

• https://fidoalliance.org/specifications/download/

  
  

• https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-appid-and-facets-ps-20141009.html

  
  
• https://developers.yubico.com/U2F/

If you would like to learn more about U2F and its implementation, as well as about other solutions of the FIDO alliance, write in the comments.