Now you can trust FIDO too

Updated: Feb 10, 2020

Back in the 1850s, before he became president of the United States, Abraham Lincoln named his dog FIDO. FIDO stems from the Latin meaning “to trust or confide in”. An apt choice for a dog’s name, but little did he know that 165 years later, we would be trusting in our FIDO2 security.

It’s long been recognised that passwords are the weakest link in authentication ecosystems; however, in many cases, they are the only way to authenticate a user. FIDO2 changes that with the implementation of Internet-scalable protocols that will allow users to authenticate using passwordless strong authentication to websites and services.

If you’re curious and want to know how FIDO2 works and why we can trust it, you might well get buried in a myriad of acronyms. U2F, UAF, CTAP, and WebAuthn, to name just a few. In this blog, I will provide a succinct but techie explanation of FIDO2. You may also like to view this recording of a webinar I presented in January 2020.

Why are we at risk today?

Passwords are a shared secret between a user and the target system. The target system is referred to as a relying party (RP). The RP may be a website with its own authentication database or an identity service provider offering federated authentication to many websites and services. Let’s just look at how passwords are compromised:

  • A user is required to create the password

  • Users are predictable, how many passwords based on seasons, movies, and soccer stars are in use?

  • Remembering multiple passwords is a challenge which results in the same credentials being used on multiple RPs

  • Password resets are possibly performed via an email account or Knowledge-Based Authentication (KBA) security questions and answers

  • The email account may have been compromised

  • The user may have already revealed the answer to the KBA questions via social media

  • Users reveal their passwords via phishing attacks either revealing their password via social engineering or being duped into entering their credentials on a fake website

  • Passwords can be captured via a man-in-the-middle attack and replayed

  • The target system holds a database of usernames, passwords and possibly KBA questions and answers

  • Databases are being breached all the time and the security of stored credentials on many occasions is poor

  • Check to see if your credentials have been leaked

The majority of attacks are against low-hanging fruit using password spray attacks (trying to access accounts with predictable passwords, sprayed across multiple accounts to avoid lockout detection) or credential stuffing (using previously compromised credentials).

The good news is that if you authenticate through a service like Azure AD, Microsoft is constantly analysing sign-in behaviours, blocking traffic from IP addresses identified as malicious and generating risk signals that can be evaluated during authentication. Through the uses of Artificial Intelligence, where algorithms are being constantly tuned, signals are being generated that will allow you to improve the efficacy of your security posture. Add Password Protection where passwords are validated against banned password lists, and we are looking good. BUT. Even if you get your users to choose the best possible passwords and you automate the protection of your systems, PASSWORDS WILL BE COMPROMISED.

It’s not surprising that by turning on Multi-Factor-Authentication (MFA), you reduce the chance of an account being compromised by 99.9%. However, if passwords are such bad news, isn’t it about time that we eliminate them!

Azure AD already has passwordless authentication, when accessing a resource secured by Azure AD, a user can be prompted with a numeric value to use for authentication. The user is required to unlock their phone with a PIN or biometric and select the appropriate numeric value displayed via the authenticator app. The sign-in process is completed with no password. What’s more, the sign-in is strong authentication equivalent to MFA because it meets the criteria of something you know or something you are and something you have. You possess the phone and authenticate yourself to the phone using a PIN or biometric. Figure 1 shows a passwordless sign-in.

If the end goal is to eliminate passwords, the solution needs to be scalable for all systems that perform authentication on the Internet. Along comes FIDO2… FIDO stands for Fast Identity Online.

A brief history

The FIDO Alliance was founded in July 2012 with a mission to work on creating a passwordless authentication protocol. In December 2014 it published the passwordless protocol FIDO Universal Authentication Framework (FIDO UAF) and the second-factor protocol FIDO Universal 2nd Factor (FIDO U2F)

Over the years the alliance has attracted many vendors, and the work of the alliance has matured and is now backed by a certification program. 2019 is significant because of the adoption by the World Wide Web Consortium (W3C) of the FIDO2 core Web Authentication protocol (WebAuthN) as an official web standard. This immediately opened the door for a significant number of vendors to go to market with FIDO2 security Keys. Microsoft Windows Hello achieved FIDO2 certification in May 2019, and you can now use Windows Hello PIN or biometrics to access online services and networks that are FIDO2 certified. If you are running Windows 10 with Windows Hello and are curious to try this out, you can go to (a site sponsored by DUO). Register a user name and then sign in using your Windows Hello PIN or biometric. See Figure 2. You can use any name to register with the site and access is pseudo-anonymous, preventing tracking between sites.

In a nutshell, how does it all work?

Let start with a really simple explanation and then fill in the details. A user needs to be able to prove their identity to the RP. In a world of passwords, you prove your identity by submitting your user name and password, but we now know how insecure this is. How can we prove to the RP who we are using a secret that only we know and never divulge to anyone?

The answer is to use public/private key (asymmetric) encryption. In response to an authentication challenge from the RP, a cryptographically signed statement is created that identifies the user. The statement is signed with a private key that that never leaves the user’s possession. The RP verifies the signature using the user’s public key, which has been previously registered with the RP and accepts the verified statement as proof of authentication.

Before we can authenticate, we need to register with the RP. These two separate operations are referred to as an authentication ceremony and a registration ceremony.

Registration Ceremony

Before or during the registration ceremony, the RP creates an account for the user. On the client-side, a public/private key pair for use with the RP is generated by a crypto hardware device called an authenticator. Before the authenticator generates the key pair, the user is required to consent. Depending on the security requirements, consent can be given via a gesture (for example touching, the authenticator) or authenticating to the device either with a PIN or biometric. The public key is passed to the RP and stored with the user’s ID. The private key is stored with an RP identifier and is scoped so that it can only be used with the one RP.

Figure 3 shows an authenticator with key pairs and the associated RP identifiers. The RP stores userIDs and the associated public key.

The authenticator could be an integral part of a platform such as the TPM used with Windows Hello, a security key or a mobile phone. These are referred to as platform authenticators and roaming authenticators.

There are options for how the private key is managed/stored. The key can either be resident (stored) in the authenticator or encrypted (wrapped) and sent to the RP for storage. Resident keys can be used directly from the device, whereas encrypted keys must be returned by the RP and decrypted by the device for use in the authentication ceremony. It is necessary to supply the RP with the user ID before it can return the appropriate wrapped key. The advantage of wrapped keys is that they do not take up storage on the authenticator. However, they can only be used for 2FA as it will be necessary for the user to authenticate to the RP before the wrapped key is returned to the authenticator. The authenticator can then retrieve the private key from the wrapped key and use it to sign a statement which is used as proof of possession of the key (the second factor).

Authentication Ceremony with resident private keys

The RP will send a challenge. After the user authenticates to the authenticator with their PIN or biometric, the client replies with a signed response using the appropriate private key for the RP. This signed response is referred to as an authentication assertion. Using the user ID, the RP can access the associated public key to validate the signature, and the authentication ceremony is complete. See Figure 4.

We need protocols

The protocol that defines the registration and authentication flow is WebAuthn, but we also need a protocol for communicating with the authenticator. The device could be an onboard Trusted Platform Module (TPM) as used by Windows Hello or a FIDO2 security key. The protocol for communicating with FIDO2 security keys (authenticators) is the Client to Authenticator Protocol version 2 (CTAP2). Web Authn allows for the use of the earlier U2F keys, that can be used for second-factor authentication, this support is via CTAP1. The physical communication to the authenticator could be USB, NFC or Bluetooth Low Energy (BLE). See Figure 5.

More details…

Registration ceremony

The RP starts the ceremony by instructing the client to create a new credential. The RP can specify various options that it requires for the new credential. As part of this process, the RP will create a data structure which includes the following (for an illustration of the registration ceremony flow see Figure 6):

RP-to-client create credential request

  • Challenge: Random string of bytes, used to prevent replay attacks

  • RP: Information about the RP including an RPId which is either the RP’s domain or a registrable domain suffix of the RP’s domain. This is used to scope the credential so that it will only be used with the RP that is conducting the registration ceremony.

  • User: Information about the user who is registering, it includes a randomly generated id that is used to associate a credential with a user.

  • pubKeyCredParams: Specifies the cryptographic types of public keys that are acceptable to the RP.

  • authenticatorSelection: Optional parameter which can be used to specify: > The type of authenticator - cross-platform (roaming) or platform > If the authenticator private key should be residential > If user verification to the authenticator is required, preferred or discouraged

  • excludeCredentials: Optional, can prevent the creation of a credential for an existing user.

  • timeout: The user is required to respond within this time; otherwise, an error occurs.

  • attestation: Allows the RP to specify if attestation data is required. The options are none, indirect, direct. Attestation data allows the RP to verify the veracity and the security of authenticator being used. For a social website, this is probably not required, but a banking website may require a particular type of authenticator with high assurance MFA. The attestation statement is signed using a manufacturer’s private key. The private key and the attestation public key cert are burnt into the authenticator when it is manufactured. An attestation has information that could be used to track a user, the indirect option allows the attestation to be anonymised.

The client receives the create credential request

When the create credential request is received by the client, the client verifies that the RPid matches the origin of the request as seen by the client. If there is a mismatch, this could be a phishing attack and the request is rejected.

clientData is created by concatenating the challenge and origin, this is hashed and passed with the rpId, userId and other details received to the authenticator. The reason that the hash of the clientData is sent to the authenticator is so that it can be signed and consequently validated by the RP.


Based on the create credential policies, the authenticator prompts the user to identify their presence or verify with a PIN or biometric. A public/private key pair is created for the relying party. The private key, a newly created credential ID and the rpId are securely stored in the authenticator.

A response is built which includes the userId, the credential ID and the public key. Depending on the attestation requirements, see attestation above, the data and the hash of the client data are signed using the attestation private key. The attestation certificate and public key can be added to the response.

The client adds the clientData to the response from the authenticator and returns it to the RP.