↓Skip to main content
Aura Research Division
Universal Second Factor - Phishing-proof 2FA for general human beings

Universal Second Factor - Phishing-proof 2FA for general human beings

Yuriy Ackermann
MFA/2FA U2F Fido

Background
#

It’s a well known fact that making the Internet secure is hard. We have to work with a massive technological base, trying to push the best solutions in the world of legacy code bases. At the same time, we need to ensure that users are up to date with their understanding of basics of information security. All this must be done whilst trying to keep things simple, because your grandma isn’t going to use PGP. It’s a game of chasing rabbits...

With the rise of Web 2.0 we started to understand that passwords are simply not enough, and hence multi-factor authentication (MFA) was born.

MFA is a method of access control that uses different artifacts in order to authenticate a user. Usually, these artifacts are based on possession (something the user has) and knowledge (something the user knows).

A common example of MFA is your credit card. There is something you have, your card, as well as something you know, your PIN. The PIN without the card is pointless, as is having the card without the PIN.

Today, we’ll only talk about one specific type of MFA: two-factor authentication (2FA). It uses only two factors for authentication, hence the name.

There are three main types of 2FA that are in wide use today:

  • Short Message Service (SMS) - one time passwords generated by a relying party and sent over SMS.
  • One-Time Passwords (OTP) (Time- or Hash- based, TOTP/HOTP) - one time passwords generated from a shared key. Examples: Google Authenticator, Yubikey, or Bank OTP tokens.
  • Cryptographic tokens - hardware devices for performing multi-factor authentication and digital signatures. Examples: RSA SecureID, RuToken, Yubikey, etc.

Even with these solutions we didn’t manage to solve the existing issues. Let’s look at the reasons why current 2FA solutions have failed:

  • Phishing - nearly all of the listed solutions are susceptible to phishing and MITM (Man In The Middle) attacks. Ask yourself: If the user already gave their username and password, what’s going to stop them from giving away their OTP token as well?
  • Security - this particularly applies to SMS, the most popular 2FA solution on the market. It’s easy, accessible, diverse and terribly insecure. Not just when considering the security of GSM protocol, but social engineering attacks against SIM recovery mechanisms have been widely known to be active in Russia, the USA, South Africa, the UK and other locations.
  • Price - if you have large amounts of cash, a bank will most likely be happy to provide you with one of its RSA tokens. But if you run a blog about cats, you won’t be able to provide or demand tokens from your users.
  • Compatibility - a lot of hardware solutions require drivers. Installed software and drivers such as Java browser plugins become a major wall in deploying 2FA solutions to customers.
  • User experience - despite having secure, cryptographically strong unbreakable solutions on the market, your users will not use them if they are hard to use.

FIDO Alliance
#

As a response to these issues, the FIDO Alliance consortium was organised in 2013. Today, it’s a multinational organization with over 270 members, including a board made up of such companies as Google, Microsoft, Visa, Paypal, MasterCard, Bank of America, Yubico, and RSA. Its mission is to develop strong, secure and easy to use authentication protocols.

At this stage FIDO has presented three protocols:

  • FIDO Universal Second Factor (U2F) - a digital-signature challenge-response protocol for second factor authentication
  • FIDO Universal Authentication Framework (UAF) - a digital-signature challenge-response protocol framework for secure authentication and transaction confirmation with an emphasis on device-specific key pairs and biometric authentication.
  • WebAuthn - a W3C proposed standard API for accessing Scoped Credentials.

In this post we will only look at U2F, but a lot of ideas overlap between the protocols.

FIDO U2F - Universal Second Factor
#

U2F is an open, driverless, digital signature challenge-response protocol for secure two factor authentication.

There are three layers of abstraction behind the protocol: the user, the client (i.e. browser), and the protocol itself.

User
#

From a user perspective, authenticating using U2F is a simple process: type your username and password, insert the token, and press the button.

Client
#

On the client, the algorithm is:

  • User logs in using their username and password
  • The relying party (e.g. Google) sends a challenge to the client (e.g. browser)
  • Client transfers this challenge request to the token

If the user confirms their decision to perform second factor authentication (i.e. they touched their token’s button):

  • The token generates a cryptographic signature over the challenge
  • This response returned to the client
  • The client passes the response to the relying party
  • The relying party verifies the signature
  • Profit!

Protocol - five (and a half) steps for secure second factor authentication
#

Step One - Challenge/Response
#

We start with the challenge/response scheme. Here, the relying party sends a random challenge to the client, which forwards it to the hardware token, which creates a cryptographic signature of the challenge. This signature is sent the client to the replying party, who using the user’s public key can verify that the signature is valid.

Challenge-response at its core does not solve phishing issues. At this stage, the protocol is still susceptible to MITM attacks.

Step Two - Phishing Protection
#

In order to mitigate MITM attacks, and make authentication phishing-proof, the client adds a location identifier, origin, or the URL that the user came from. This way, if the user gets phished, for example by being tricked to open goog1e.com, the cryptographic signature will be created for goog1e.com and not google.com. The relying party will be able to detect this and so reject the authentication request.

Step Three - Privacy and Registration-Specific Key Pair
#

Using the same key pair for generating all of the signatures poses major privacy risks. For instance, if you are using your token for a general service such as Gmail, and a service that you’d rather keep private, like AshleyMadison, the leak of the public key of your token may lead to cross-site identification that may be harmful to the token owner.

In order to mitigate such issues, for each registration operation, the token generates a random key pair that is stored in the token’s secure memory, or wrapped securely with the master key. The key pair is then identified using a random keyHandle (key ID) and appID. appID is a unique application identifierthat is usually a simple URL, such as https://google.com. The relying party stores keyHandle in its database, and provides it to the token during authentication.

A nice side effect of having registration specific key pairs is that you can share your token between multiple accounts on the same service and relying party will never be able to tell that you are doing so. So you can share a single token between you and your partner.

Step Four - Cloning Protection
#

If there is a possibility that a U2F token can be cloned, we also need some way to detect it. We can do this by having an operation counter. Every time a cryptographic operation is performed, the counter increases by 1. The value of the counter is signed and sent as part of the response to the relying party, which stores the value of the counter in its database. If the counter value in a future authentication response is less than the counter value stored by relying party, then the token has been cloned, and the relying party must decline the authentication request. It should probably also log the event occurrence and/or perform necessary actions to secure the user, by for example blocking token from further authentication attempts.

Step five - device attestation
#

Since U2F is an open protocol, multiple implementations are available on the market. Some relying parties might require certified devices, like US government organizations which are required to use FIPS certified devices for security purposes. To be able to identify the type of the device, the U2F protocol provides a device attestation mechanism. For each batch of the devices (specification states batches of hundred thousand or more devices), new batch key pairs are generated, with the private key placed in the devices. The public key is then signed by the vendor, and certificate published in the online metadata directory. Each token’s response is then additionally signed by the private key, which isattached to the response. The relying party can then identify what type of device is being used, and therefore control which type of device it accepts.

Step five and a half - bruteforce protection
#

In the situation when the user is away from keyboard, malicious software may try to perform key recovery or perform a bruteforce attack on the key to generate malicious responses. In order to mitigate this, U2F standard demands a user action (or user gesture) to perform cryptographic operations. What the user gesture must be is up to the vendor, and so there are many types of “gestures” that exist on the market, such as pressing a button, fingerprint verification, entering a PIN, and others.

ApplicationID and Facets
#

Until now we’ve talked about applications with a single authentication endpoint. However, the web is diverse. For example, look at Gmail. Gmail has web, iOS, Android, and Windows applications:

To define an application with multiple authentication endpoints, we need to look at the two different scopes of application identification:

  • appID - a URL ID that defines the authentication group of an application. Think of it like a street address.
  • facetID - a URI/URL ID that defines a single authentication endpoint that is within the appID authentication group scope. Think of it as an apartment number on a particular street.

Single Authentication Entry Application
#

If you have an application with an appID of, for example, https://example.com, that has only a single authentication endpoint https://example.com, then your facetID is your appID, which in this case is https://example.com because you are authenticating to https://example.com.

Application with Multiple Authentication Endpoints
#

In the example of Gmail:

  • appID: https://google.com/facets.json
  • 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"
      ]
    }
  ]
}

A facet must be an HTTPS URL with a host that is a sub-domain of the domain of the appID, or a special URI identifying a mobile phone application. In the case of an Android application, this is an URI derived from the SHA-1 hash of the APK signing certificate, and in iOS the facetID is defined by the app’s bundleID.

Facets must be served over valid HTTPS. If you are planning to play with developing a multi-facetted application, self signed certificates will not work.

Transport Protocol Support
#

FIDO have released specifications for USB, NFC and Bluetooth Low-Energy (BLE).

Browser Support
#

  • Chrome has supported U2F since 2014.
  • Software tokens are already available in Mozilla Firefox, and hardware support is in active development.
  • The Microsoft Edge team has stated that they are not interested in supporting U2F yet.

Adopters
#

Current adopters include companies like Google, Dropbox, Facebook, Github, Gitlab, DUO, Dashlane and even the UK Government.

Tips
#

Here are a couple of things you might want to know before you move to U2F:

  • HTTPS is mandatory - Both Firefox and Google clearly stated that they will support U2F only for secure websites.
  • Facets must be served over valid HTTPS - browsers are very picky about certificate security, and if you are using self signed certificates, you will not be able to play with facets. Let’s Encrypt might be useful for that.
  • Facets are explicit - No wild-card domains are allowed. You have to state each host that will be allowed to perform authentication with U2F.
  • U2F is a second factor, and is not designed to be a primary factor.

Summary
#

U2F is an open, easy-to-use and secure protocol. It’s designed to improve user security through ease of use, making it easy even for your grandma to use, but still hard for hackers to break it.

Things to Play with
#

References
#

Disclaimer
#

The information in this article is provided for research and educational purposes only. Aura Information Security does not accept any liability in any form for any direct or indirect damages resulting from the use of or reliance on the information contained in this article.