Introduction

Passwords are a problem and you’d be hard-pressed to find a security professional who disagrees. According to Verizon’s 2019 Data Breach Investigation Report, 62% of breaches involved the use of stolen credentials, brute force or phishing. TeleSign’s Consumer Account Security Report 2016 states that 71% of accounts are guarded by passwords used on multiple sites. Another report shows that 86% of users would like to replace work-related passwords with fingerprint recognition technology if given the option. Also, according to a Forrester report, there is a consensus on the need to move away from passwords. Kaspersky states that the vast majority of data breaches are caused by stolen or weak credentials.

Report after report details the same problem, passwords. In this post, we look at a potential solution to the password problem and have a look at FIDO2.

The Problem With Passwords

Passwords have been the standard means of authentication for decades. However, there are many issues with password-based authentication, namely:

Users can have trouble remembering passwords so they use short passwords or passwords based on personal or public information. Short passwords can be quickly brute-forced. Passwords based on personal or public information can be guessed and may be vulnerable to dictionary attacks.

Users re-use the same password on multiple websites. Password leaks are common. If a re-used password has leaked, all accounts where that password is re-used are vulnerable to password spraying.

Strict password policies can be counterproductive. Indeed, they may force users to use special characters. However, a long password is more secure than a short password with special characters. Additionally, the long password may not contain special characters and may be easier to remember than the shorter but more complicated password.

Phishing attacks are common and often allow attackers to obtain passwords.

Even if passwords are not re-used and long enough, remembering a different password for each service quickly becomes an issue. Password managers partially solve the problem but leave room for improvement. Indeed, some password managers require you to trust the provider that stores the passwords for you. Local password managers also exist but are usually less user-friendly and may not run on all platforms such as on a smartphone.

Those issues are especially concerning if the password is the only authentication factor used to secure an account. Today, this is still the case for the majority of users. Very few users enable two-factor authentication. This can be explained by a few reasons. The first is the lack of communication with end-users about these features. Some people only know of one way to authenticate: passwords. The second reason is that two-factor authentication is more cumbersome. It takes additional time to sign in and may require buying an additional device in some cases.

FIDO2 comes to the rescue and introduces new ways to authenticate, hoping to solve most of the issues mentioned above.

What is FIDO2?

FIDO2 uses public-key cryptography to provide strong passwordless authentication to end-users. On top of that, FIDO2 not only enables passwordless authentication but multiple authentication flows as well, including single factor (1FA), two-factor (2FA) and multiple-factor authentication (MFA).

To be more specific, FIDO2 is the name given to the combination of two specifications. These specifications are:

WebAuthn (Web Authentication), and

(Web Authentication), and CTAP (Client to Authenticator Protocol)

WebAuthn

The WebAuthn specification describes an API between a Client – for example, a web browser – and a Relying Party (RP) – for example, a server at example.com. The Client is the application/web browser / operating system trying to access a service offered by the relying party. The relying party is the server that wants to authenticate the client. Clients communicate with an Authenticator, a device that securely generates and stores public-key credentials used for authentication. The public key algorithm used depends on the authenticator that is used. The protocol describes a method for clients and relying parties to decide on the algorithm used based on the preferences of both the client and the relying party.

WebAuthn describes a procedure that clients and RPs must abide by to support FIDO2 authentication flows. Use cases for WebAuthn include:

Registration : a user registers on a new website or service using an Authenticator

: a user registers on a new website or service using an Authentication : a registered user authenticates on a website or service using an authenticator

: a registered user authenticates on a website or service using an authenticator New device registration: a user adds a new Authenticator to their account. The user will then be able to authenticate using any of their registered authenticators.

CTAP

The CTAP protocol defines an API between an authenticator and a client platform (web browser, operating system, etc.). In other words, it is a protocol used by clients/web browsers/operating systems to communicate with an external authenticator device. Prior to interacting with an authenticator, a client must establish a connection to the authenticator either via USB, Bluetooth or NFC.

In FIDO2, the previous U2F standard was renamed to CTAP1. On the other hand, CTAP2 is the newer standard used in FIDO2.

Authenticators

An Authenticator can be either:

a roaming authenticator , which is an authenticator that can be attached to multiple devices. Examples are USB, Bluetooth or NFC authenticators.

, which is an authenticator that can be attached to multiple devices. Examples are USB, Bluetooth or NFC authenticators. or a platform authenticator, which is an authenticator that is embedded inside a device such as a smartphone or a laptop and that cannot be disconnected from the device.

Every authenticator must implement the CTAP protocol so that clients can communicate with it in a standardized way.

Examples

Here are a few examples of authenticators.

Yubico Security Key NFC used on a smartphone via NFC

SoloKeys Solo used on a laptop via USB

Yubico Yubikey 5 NFC used on a smartphone via NFC

FIDO2 compatible Google Titan Security Key model K13T (left) supports Bluetooth and model K9T (right) supports NFC.

FEITIAN BioPass FIDO2 (K27) includes a fingerprint reader for Multi-factor authenticaton via USB.

Any smartphone running Android 7.0 or later can be used as a FIDO2 (platform) authenticator. The smartphone itself is the authenticator. No additional device required.

iPhones running iOS 13 or later can now use FIDO2 authenticators via NFC.

MacBook Pro with a Touch Bar supporting Touch ID (fingerprint recognition) acts as a FIDO2 platform authenticator with Google Chrome.

FIDO2 certification levels

Authenticator manufacturers have the opportunity to have their devices FIDO2 certified. Certification is optional but may give more credit to a device. Vendors can apply for a certain certification level. The certification goes from level 1 (least secure) to level 3+ (most secure).

FIDO2 certification label

For example, an authenticator certified for level 1 could be an authenticator storing private keys without any special protection. To obtain higher level certifications, the authenticator should use more secure elements such as:

a keystore that runs in a trusted execution environment,

hardware with certified anti-tampering measures,

or protections against fault attacks or other side channel attacks.

Authentication flows

There are a few possible authentication flows with FIDO2. We will describe these flows for both registration and authentication. In all cases, the user needs a FIDO2 compatible authenticator such as a smartphone or a security key.

Registration ceremony

This is the process for a user to register a new account on a website/service.

The user visits the website with his web browser and clicks on “Sign up”.

The user enters a username or email address and clicks the Sign up button.

The web browser asks the user to authenticate using their authenticator.

If the authenticator is a platform authenticator such as a smartphone, it will usually ask the user to perform a previously platform-defined authorization gesture such as presenting a fingerprint or entering a PIN.

such as presenting a fingerprint or entering a PIN. If it is a roaming authenticator, the user will be asked to tap on the authenticator to check for physical user presence (up).

(up). In the case of MFA (multi-factor authentication), the authenticator may do additional and optional user verification (uv), such as asking for a PIN or biometric recognition.

(uv), such as asking for a PIN or biometric recognition. The website says that the user has been successfully registered.

This user presence and user verification values are sent by the authenticator. The specification describes an Attestation mechanism to attest to the provenance of an authenticator and the data it emits. Relying parties can verify the attestation signature and make sure that the emitted data comes from a trusted authenticator. Thus, allowing relying parties to trust authenticators that claim user verification was performed.

Note that whenever an authenticator is used to register a new account on a relying party in 1FA (passwordless) mode, the authenticator generates a key pair (public/private) and stores the private key on the authenticator itself. Such a key pair whose private key is stored on the authenticator itself is called a resident credential. The user’s associated public key is sent to the relying party, who is responsible for storing it and later using it to authenticate the user when they sign in using their corresponding private key.

FIDO2 has a notion of scope. Indeed, generated credentials are scoped to a given relying party ID (RP ID) – in practice this RP ID is the domain name of the website. This means that the private key can only be used to authenticate on the same relying party for which that key was generated, thus completely eliminating the phishing problem.

Some authenticators can store a limited amount of keys and these limits are usually found in the authenticator specifications. That number can be 25 (Yubikey 5), 50 (Solo Key) or over 100 depending on the product used. When FIDO2 is used in 2-factor mode, there is no limit to the number of sites it can be used on.

Authentication ceremony

This is the process for a user to authenticate on a website/service where they previously registered.

The user clicks “Sign in” on the website.

The user enters their username or email address and clicks the sign in button.

The web browser asks the user to authenticate using their authenticator, same as during registration.

The website says that the user has successfully signed in.

Usernameless authentication is also possible. FIDO2 makes it possible to sign in to a website just by plugging your authenticator into the USB port (for example) and tapping on it. No username or password required. In this case, the client is responsible for displaying an account selection dialog to the user.

When authentication is performed, the authenticator produces an assertion signature that asserts that the user has consented to perform an action, such as signing in. The assertion asserts that the authenticator that has the private key believes that the user who wants to sign in (or any other action requiring authentication) is the same user who registered in the first place with the corresponding public key.

Note that Attestation and Assertion are two different concepts. In both cases, the authenticator produces a signature but these are used for different purposes. An attestation signature is produced when a new key pair is generated, during registration. An assertion signature is produced when a registered user wants to sign in.

U2F backward compatibility

FIDO2 supersedes the old U2F protocol used for 2-factor authentication. Indeed, a FIDO2 authenticator can be used, both for passwordless first-factor authentication and for 2-factor authentication. However, that does not mean people owning an old U2F security key should throw it away. Someone using a security key supporting the old U2F standard can still use it for 2FA on services implementing the newer FIDO2 standard.

Public key algorithms

The public key algorithm used for the key pair is configurable and can be any of the COSE algorithms described on this page. Similarly to TLS, the Relying Party and the Client should negotiate the algorithm by sending a list of preferred algorithms. An authenticator may support only one public key algorithm. If the relying party doesn’t support that one public key algorithm then that authenticator cannot be used with that website. Authenticators may support, for example, ECDSA with SHA-256 (public key algorithm value -7 on the page linked above).

FIDO2 features

FIDO2 has many advantages over regular passwords:

No need to remember passwords

Invulnerable to phishing attacks. FIDO2 makes sure that the website the user signs in to is actually the one they think it is. The protocol binds a key pair to a website. Therefore it is impossible to use credentials that were generated during registration on site A to sign in on site B.

The lowest security level of FIDO2 (single factor authentication) is more secure than regular password-only authentication in most cases.

Applications handling sensitive data can be secured with FIDO2 multi-factor authentication (biometric or PIN) when the highest level of security is required.

Security level is configurable and on-demand per application/user (1FA, 2FA, MFA).

Authenticator cloning detection. If someone steals your authenticator and clones it, the protocol has a built-in way to detect if the clone was used.

How secure is 1FA/passwordless compared to a regular password?

Let’s say the FIDO2 resident credential was generated with ECDSA with the NIST P-256 elliptic curve and hashed with SHA-256. Therefore we have 128 bits of security for 256 bits keys. Now, let’s say a regular password uses printable characters only that use 7 bits each. This means the passwordless/1FA FIDO2 key is stronger than an 18-character long password including lowercase and uppercase letters, numbers and special characters. A password of that length and complexity would take billions of years to brute force and can be considered safe.

Additionally, FIDO2 guarantees that a different key is generated for each site and also for each account, in case you have multiple accounts on a single site. Plus, there is no need to remember any password. This looks like quite an improvement over regular passwords. If extra security is needed, FIDO2’s 2FA or MFA modes can be used.

What happens if someone finds your private key by brute forcing?

First, this is very unlikely because the security of your key pair is already very strong. However, in the event that this would happen, only the account associated to that key pair would be compromised. All your other accounts would still be safe. Since a new key pair is generated for every new account, the “password re-use” problem is avoided.

What happens if you lose your authenticator?

If you lose your authenticator, you may be locked out of your account. To prevent this, it is recommended to register multiple authenticators on a single account. So that you have at least one backup authenticator in case your primary authenticator is lost.

What happens if your authenticator is stolen or cloned?

Your authenticator securely authenticates you and is secure against network attacks. However, if someone physically steals your authenticator, they may be able to authenticate in your place.

To protect against this, there are a couple of measures one can take:

Use multi-factor authentication. For example, secure your authenticator with a PIN or a fingerprint. Authenticators supporting PINs keep a retries counter, indicating how many more times a wrong PIN can be inserted. After 8 wrong PINs, the authenticator has to be reset (all keys are erased) to be used again. Also, after 3 successive incorrect PINs are entered, the device is blocked until it is unplugged and plugged in again. This prevents malware from automatically entering wrong PINs on purpose to force people to reset their device.

Immediately revoke the lost/stolen authenticator from websites where it was registered. This may require using a previously registered backup authenticator.

If your authenticator is cloned by an attacker, FIDO2 implements a way to detect clones. This will not prevent the cloned authenticator from being used once, but it will at some point eventually make you aware that someone else authenticated using a clone and will not leave it undetected.

What is the difference between a password and a PIN?

A password transits on the network and can be intercepted. A PIN is local and never leaves the client machine. Therefore, a PIN does not need to be as complex or as long as a password and does not need to be changed as often.

Example on microsoft.com

Step 1 – Registration

Note that the following was performed on a Windows 10 machine using Google Chrome. The authenticator used was a Yubico Security Key NFC and it was used over USB.

Microsoft accounts support passwordless sign in with FIDO2. We assume that the user already registered an account on microsoft.com using a username and a password. We can however imagine other sites where users sign up with only a security key and no password is asked from them at any time.

The user should first add a security key to their microsoft.com account. This can be done from the “security” options page and then the “more security options” page. During this process, the web browser may prompt the user for a few things.

The website may force the user to use a PIN protected key depending on the policy. That policy is configurable by the website. If no PIN is set, the browser will ask the user to setup a new PIN. If the authenticator does not support PINs, then that authenticator cannot be used with that site. For example, a banking site may want to enforce extra security and make sure user verification is performed using a PIN or biometric. Note that this PIN is global and needs to be set only once for the authenticator.

Google Chrome asks the user consent before allowing the relying party to access authenticator information.

Of course, this procedure can be performed for every account that we have.

Step 2 – Authentication

Now that the authenticator has been added to the account, one may sign in with it.

Sign in form offering the option to sign in with a security key (no username or password required).

Google Chrome prompting the user to insert the security key and touch it.

Google Chrome asking the user to enter the PIN for a PIN-protected authenticator (MFA).

Google Chrome asking the user to touch the key again after entering the PIN.

Google Chrome asking the user to select the account to sign in when the user has keys for multiple accounts on the same website.

Services supporting passwordless FIDO2

Today, there are a few services supporting FIDO2. Here are a few examples.

Microsoft, as shown above, allows usernameless and passwordless sign in to your Microsoft account (usernameless 1FA)

Microsoft Windows, allows to sign in to your Windows session without a password (1FA). Note that Microsoft Hello can also act as a FIDO2 authenticator.

webauthn.io, a demo website for FIDO2, supports 1FA/passwordless

On a side note, Github recently announced their support for FIDO2 for 2FA scenarios and are working on implementing 1FA support.

Client support

FIDO2 is supported by many web browsers and platforms. It is however important to note that FIDO2 was not solely designed to work in web browsers. It can also be used in command-line applications, heavy clients or mobile apps. You name it.

Web browsers

Most major web browsers currently support FIDO2, both on mobile and on desktop. Note that the diagram below is slightly outdated (March 2019) and that web browser support has improved since March. Indeed, Safari macOS now supports FIDO2 over USB (should be green) since Safari 13. Firefox Android is not on this diagram but supports CTAP2 over NFC. CTAP2 over USB is an experimental feature that is disabled by default on Safari iOS. Finally, some progress has been made and iPhones now have the ability to write over NFC since iOS 13 so support for CTAP2 over NFC on Safari iOS should be coming soon.

FIDO2 support in web browsers as of March 2019 – Source









Enabling Safari’s “Web Authentication” experimental feature on iOS.

Conclusion

According to various reports, stolen passwords are the most frequent cause for data breaches, by strengthening authentication mechanisms a drastic reduction in attack surface can be accomplished. Adopting FIDO2 is a good candidate for creating stronger authentication without drastically increasing friction.

FIDO2 authenticators are available today and the number of websites supporting it is growing. The easiest way to try it is probably to use an Android 7.0+ smartphone, a Windows PC that has Windows Hello configured or a MacBook that has Touch ID configured. All of these platforms can act as a FIDO2 authenticator. This way, no additional device is required. However, it will only be possible to authenticate that way on your particular device. In case you do not have access to these platforms, buying a FIDO2 compatible security key such as a Yubikey 5 or a Solo Tap is probably the best option. Make sure the authenticator will work the way you want to use it, be it over USB, NFC or Bluetooth.