FIDO explained: How this industry initiative aims to make passwords obsolete

FIDO definition: What is the FIDO Alliance and what does FIDO stand for?

The FIDO (fast identity online) Alliance is an industry association that aims to reduce reliance on passwords for security, complementing or replacing them with strong authentication based on public-key cryptography. To achieve that goal, the FIDO Alliance has developed a series of technical specifications that websites and other service providers can use to move away from password-based security. In particular, the FIDO specs allow service providers to take advantage of biometric and other hardware-based security measures, either from specialized hardware security gadgets or the biometric features built into most new smartphones and some PCs.

The FIDO Alliance came together in 2013 as security pros working at PayPal, Lenovo, and other companies began to get fed up with various password-based security holes. The group has been plugging away at its goal for a while — “FIDO Alliance Says, Forget Passwords!”, CSO declared not long after the group started up — but with biometric readers becoming more and more prevalent and a new set of specs that are easy to integrate into standard webpages via JavaScript APIs, our passwordless future may finally be in sight. FIDO Alliance members include some of the biggest names in tech and media, so this initiative has muscle behind it. 

FIDO specifications

Before we get into the individual FIDO specifications, we need discuss the principle that they’re all based on: public key cryptography. In this form of cryptography, each communicating party uses two keys — very large numbers — to encrypt messages via an encryption algorithm. Each party shares a public key that’s used to encode a message, which can only be decoded by a private key, which is kept secret. The two keys are related by some mathematical operation that would be difficult or impossible to reverse — for instance, the private key might be two very long prime numbers and the public key would be the number you get by multiplying those two primes together. (For more on how this works, check out CSO’s explainer on cryptography.)

Public key cryptography is already the basis for most secured internet communication. The SSL/TLS standard is based on it and has been built into most web browsers for decades, and the larger set of technologies and specifications known as the public key infrastructure, or PKI, helps not only encrypt data but also ensure that communicating parties online are who they say they are. In almost every case today when you enter a password into a web browser, that password is being transmitted across the network in an encrypted form, thanks to PKI.

So why does the FIDO Alliance want to get rid of passwords? Well, even with strong encryption, any system that performs authentication by exchanging passwords between two different computers over the internet has vulnerabilities. Encryption isn’t perfect, and isn’t always implemented perfectly, so it’s still sometimes possible to intercept passwords in transit. And a password system requires that a service provider keep a list of user passwords on its servers; such a list should itself be encrypted, but that doesn’t always happen, and that makes a tempting target for hackers.

The various FIDO specifications all address these fundamental weaknesses by shifting authentication entirely to the devices that are local to the user. These local devices then tell the service provider, via communications protected by public key encryption, that the user has been authenticated, without actually transmitting any sensitive information about the user.  The different FIDO specs take somewhat different roads to that destination, however. We’ll start by looking at the first two specs the FIDO Alliance released, UAF and U2F, before digging into the newer FIDO2 spec currently seeking wider adoption. 

FIDO UAF

The FIDO UAF standard — the initials stand for Universal Authentication Framework — is focused on authentication for users of digital devices like smartphones or tablets. To access a service using the UAF standard for security, the user would register their account via their device, which would then request that the user authenticate themselves using some security protocol the device natively supports. Once this authentication has occurred, cryptographic keys — but no other authentication data, like a password or biometrics — are exchanged between the device and the service provider. The user can subsequently sign in with the same authentication technique to access their account.

One important feature of UAF is that, even though service providers never see the specific authentication data used for login, they do know what type of authentication method has been used, and can choose what types they’ll accept. For instance, while the UAF spec allows end users to authenticate using their mobile phone’s PIN code, a service provider could decide they don’t think that’s a strong enough authentication method and require a thumbprint or face scan instead.   

FIDO U2F

The initials in the FIDO U2F standard stand for Universal Second Factor, and so as you’d expect it focuses on providing second-factor authentication, also known as 2fa. For more on 2fa, you can read CSO’s explainer on the subject, but the short version is that it complements, rather than replaces, traditional password-based security, challenging users to make use of a second technique (or factor) to authenticate once they’ve provided their password.

Specifically, U2F defines how to use a hardware device to make logins more secure; the private cryptographic key required for encrypted communication is stored on that device. While the standard supports a number of possible devices for this purpose, the most common implementation uses a dedicated hardware security key fob. The standard was initially created by Google, which it deployed to fight phishing internally before offering it to external customers, but was then granted to the FIDO Alliance to administer. The security fob can connect to the user’s device via USB or NFC, so it can be used with PCs or smartphones.

Communicating via the browser, the fob exchanges cryptographic keys with a service provider to establish 2fa. Upon subsequent authentication attempts, the user must have their fob present, and the fob uses its key to make sure that the site that the user is connecting with really is what it claims to be. This helps prevent man-in-the-middle and phishing attacks.

As a 2fa implementation, U2F doesn’t eliminate the need for passwords. However, the FIDO Alliance believes that the extra protection U2F provides makes it safer to use simpler passwords like four-digit PINs instead of the long, complex passwords that we’re all urged to use but many find challenging to remember and manage.

FIDO vs. FIDO2: WebAuthn and CTAP

While U2F and UAF found some success, they also have limitations, as the descriptions above probably make clear. UAF makes use of security features specific to mobile devices, and thus isn’t a help on PCs. U2F can be used with PCs as well as mobile devices, but requires a separate hardware authentication key — and while security pros have been big fans of security key fobs since the early days of RSA’s SecureID, ordinary people have consistently resisted mandates that they carry yet another gadget around with them, no matter how small. While the U2F spec technically allows implementations in which a mobile phone is used as an authentication device rather than a dedicated key fob, the spec doesn’t describe ways to use most of the features of a mobile phone that might make such an implementation useful.

To address these shortcomings, the FIDO Alliance rolled out a second set of standards that built on the first, collectively known as FIDO2. FIDO2’s two standards complement one another to make both passwordless and second-factor authentication easier and more secure to implement.

The first of the FIDO2 specs is WebAuthn, which was codified by the W3C as a recommendation in 2019. Like UAF, WebAuthn uses public key cryptography to allow an end user device to authenticate a user locally when communicating with a service provider. However, unlike UAF, WebAuthn isn’t restricted to mobile devices. WebAuthn defines communications between the end user and the service provider via an open JavaScript API, so any device or PC that runs a browser that supports the standard can participate (and as we’ll see later, just about all browsers now do).

PCs are increasingly integrating hardware authentication features like thumbprint readers or facial scanners that were previously restricted to smartphones, and WebAuthn-enabled websites can make use of those capabilities to authenticate users. However, those features aren’t anywhere near universal yet, and that’s where CTAP, the second of the FIDO2 specifications, comes in. CTAP stands for Client to Authenticator Protocols, and it allows you to connect to a WebAuthn-enabled service provider with your PC while using a separate device as an authentication platform.

There are two CTAP protocols. CTAP1 is just a rebranded update of U2F, which means that you can use U2F key fobs with a WebAuthn-enabled service provider who wants to implement 2fa. CTAP2 expands on the concept, allowing devices like smartphones or wearables to connect to a PC via Wi-Fi, Bluetooth, or USB and provide authentication services, making passwordless connections possible. In essence, the FIDO Alliance is betting that, if you need to securely authenticate with an online service, you’re either using a device that supports a strong authentication method or have such a device in your pocket or on your desk.

FIDO authentication

The nitty-gritty of the FIDO authentication process can get quite in-depth, both at the level of code and of cryptography, and is beyond the scope of this article. But here’s a top-level overview of how the authentication process flow works when accessing a WebAuthn-enabled service provider. This will give you a bit more of a sense of what’s going on beneath the surface.

First, let’s consider registration. Say you want to sign up for a website or other service that uses WebAuthn:

1. You send a message asking to create an account.
2. The service provider requests a public key.
3. You authenticate yourself using some local method supported by the WebAuthn spec and accepted by the service provider. This can happen either on the device you’re using to connect to the service provider or another device that connects via CTAP.
4. Your local device generates a pair of cryptographic keys — one public, one private — associates them with your authentication data, and sends the public key to the service provider.
5. The service provider stores the public key and associates it with your new account.

Once you’ve created that account, you would use the same authentication method to log in.

1. You send a login request to the service provider from your local device.
2. The service provider requests a digital signature, a piece of data establishing your identity that can only be created by a private key but can be read by the corresponding public key.
3. You authenticate yourself on your local device.
4. Your local device correlates your authenticated identity and the service you’re trying to access in order to determine the appropriate key pair to use, creates a signature with your private key, and sends it to the service provider.
5. The service provider uses your public key to read the signature and confirm your identity, logging you in.

For a lot more details, including code examples that demonstrate how to use the WebAuthn APIs, check out this comprehensive WebAuthn guide.

FIDO certification

You may have noticed that we’ve been speaking somewhat generically about the devices and software that implements the FIDO specs. These specifications are open and can be implemented by any device manufacturers or software developers. Not everyone was on board right away, but support is now fairly comprehensive. Android has been FIDO2 certified since February of 2019; most major browsers were already certified at that point, though Apple’s Safari didn’t join the party until later in 2020.

The FIDO Alliance has resources if you’re interested in getting your own software or service FIDO compliant. There are separate compliance tracks for interoperability and hardware authenticators. Dig on in if you’re ready to help move beyond the password.