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 https://haveibeenpwned.com/
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 https://webauthn.io (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.
Authenticator
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.
Relying Party
The RP verifies the response and, if required, the attestation signature and certificate. Once verified the userId, credId and public key are stored in the RP database. See Figure 6.
Authentication ceremony
To start the process of authenticating a user, the RP sends a challenge together with a rpId and the associated credential ID (credId). See Figure 7. As with the registration ceremony, the client validates the rpId against the origin and rejects the authentication request if the match fails. The client generates and hashes the clientdata (origin + challenge) and sends it together with the rdIP and credId to the authenticator. As with registration ceremony, 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.
Authenticator
Depending on the requested credential, the authenticator prompts the user to identify their presence or verify with a PIN or biometric. Using the credId the authenticator retrieves the private key and verifies that it was created for the rpId. The authenticator then creates a response which is signed using the private key, the data that is signed includes the hash of the clientData.
Relying Party
The RP verifies the response, the signature is verified with the public key. Once verification checks are complete, the user is accepted as an authenticated user.
Usage scenarios
2FA
Before triggering the authentication ceremony, we can get the user to provide a username and password. In this case, the authenticator could just provide the second factor. The user is required to indicate their presence via a gesture such as touching the authenticator. This shows the user's intent to the authenticator and prevents malware automating the second factor if the authenticator is available (platform, USB, NFC, BLE). See Figure 8.
Passwordless
Since the user can be verified to the authenticator using a PIN or a biometric, the use of passwords sent to the RP can be eliminated. The authenticator provides strong first-factor authentication, the veracity of which is equivalent to MFA. What’s more, the RP can discover the capabilities and security of the authenticator via attestation. See Figure 9.
Passwordless and namless
The next stage is to eliminate the need for a user name. Figure 10.
The RP does not provide a credId to the client; consequently the client looks up the credentials it has for the RP. The authenticator may have credentials for more than one username, in this case, the user is prompted for which credential they want to use. Figure 11.
Summary
Let’s just look back at why passwords are bad, and you will discover that all of the vulnerabilities have been eliminated.
A user is required to create the password Not any longer, a unique cryptographic key pair is created for each site
Password resets are possibly performed via an email account or Knowledge-Based Authentication (KBA) security questions and answers Password resets are not required Multiple authenticators can be registered for recovery
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 Even if a user gave away their PIN via social engineering, an attack is not going to succeed without the authenticator All credentials are scoped for a particular relying party, eliminating phishing attacks via fake websites
Passwords can be captured via a man-in-the-middle attack and replayed The authentication challenge eliminates this possibility
The target system holds a database of usernames, passwords and possibly KBA questions and answers Gaining access to the user’s public keys has no benefit to a hacker
FIDO2 playgrounds
If you want to add a FIDO2 key for use with Microsoft Azure AD, read these two articles:
If you just want to test out registering and authenticating against FIDO2 demo websites and test out some of the options, try these:
TIP: Windows 10 allows you to reset a key and clear all the credentials. Go to "Sign-in options | Security Key | Manage | Reset". You may well receive a message that the key cannot be reset.
You will need to perform the reset within 10 seconds of powering up the key.
Call for action
Show Abraham Lincoln that you trust FIDO2oo. Enable Windows Hello today or buy yourself a FIDO2 authenticator.
Let’s work together and eliminate the need for passwords. If you found this blog useful, please Tweet me and let me know @john_craddock. You may also like to view this recording of a webinar I presented in January 2020. Signing off until next time.