What distinguishes FIDO from every other authentication protocol from the past?

Like TLS Client Authentication, it uses public-key cryptography to eliminate secrets on the server. But, unlike the X.509 digital certificate that underlies TLS ClientAuth, FIDO does not need a PKI. As a result the cost, complexity and challenging UX of using smart cards and digital certificates are obviated.

Like MFA schemes that use a hardware authenticator, FIDO uses cryptographic hardware modules that may be embedded within devices—such as the Trusted Platform Module (TPM) on personal computers, or Secure Elements (SE) on Android phones, or external authenticators called Security Keys in FIDO terminology. These hardware elements are designed to protect cryptographic keys to mitigate scalable attacks on keys.

FIDO is unique in including the following features:

• FIDO requires the generation of a new, unique key pair (public key and private key) for every website with a unique web origin consisting of a top-level domain (TLD) (such as .com, .net, .org) plus one sub-domain (such as strongkey). As a result, FIDO Authenticators generate unique key pairs for a user’s credential at strongkey.com. Every FIDO-enabled website is required to declare a relying party identifier (a.k.a. rpid). While a relying party (RP)—the company site that relies upon a FIDO digital signature to authenticate a user’s credential—may have many websites (register.strongkey.com, support.strongkey.com, login.strongkey.com, etc.), they may use the same rpid (strongkey.com) and FIDO server to support a single FIDO credential per user across all its sites. This enables authenticating the user to each site separately, providing the advantage of distributing authentication workloads across a cluster of FIDO servers while eliminating the burden of adding a legacy protocol to web applications to support single sign-on (SSO). FIDO mandates the use of TLS, so all communications on the wire are secure. However, FIDO assumes that the client platform, usually the browser, is secure—FIDO cannot protect a user from a compromised platform.
• FIDO uses two distinct protocols to communicate between the RP and the Authenticator: the W3C JavaScript API—WebAuthn—between the RP web application and the client platform—usually the browsers; and the FIDO Alliance’s Client To Authenticator Protocol (CTAP) between the client platform and the Authenticator. Since both WebAuthn and CTAP are standard protocols, users as well as RPs are freed from the burden of attempting to make a complex set of software and hardware components work together on a multitude of operating systems and devices; each platform vendor—whether it is Microsoft, Google, Mozilla, Apple, etc.—assumes the responsibility of making sure that WebAuthn and CTAP work precisely as expected on their platforms.
• FIDO allows the registration of any number of unique Authenticators to an rpid. This is unlike password technology that uses only one username and a single password. While X.509 digital certificates permit issuing unique digital certificates to the same user and allowing the user to use any of the set of digital certificates to authenticate to a TLS ClientAuth-enabled site, this is rarely done in practice. However, FIDO allows a user to use the TPM on a Windows 10 personal computer, the SE on an Android phone, the SE accessed through TouchID on a MacBook, and an external Security Key to be all registered to the same username at a specific site and use any of these four authenticators to authenticate to the site. This has the advantage of eliminating the problem of account recovery: how to gain access to your account if you lose your primary authenticator. The user simply uses another authenticator registered with the site, authenticates to the site, goes into their profile settings, deletes the lost authenticator’s registered key, and carries on. They may choose to replace the lost authenticator with a new one, but as long as a user has at least two keys registered with a site, they are unlikely to be locked out of their account. Even if both authenticators are lost/unusable, most RP sites will have a non-FIDO-based account recovery process which is likely to fall back to sending an e-mail reset link plus an OTP to your mobile, etc., to gain access to the site. Once authenticated, the user may register any number of new authenticators to their account again.
• FIDO eliminates the risks associated with password phishing. Cleverly crafted spear-phishing attacks to spurious websites that prompt for usernames/passwords are pointless if the authentic site supports FIDO-based passwordless authentication; no password is provided to the attacker’s site. Additionally, a man-in-the-middle (MITM) attack that attempts to relay a user’s authentication session through the attack site will fail since the attacker’s site will have a different domain name system (DNS)-based web origin. FIDO platforms such as browsers or rich-client apps (RCA) on mobile devices are required to map the RFC-6454v web origin to the rpid and ensure they have the same TLD+1 before using the private key to digitally sign a challenge.
• FIDO mandates a test of user presence (TUP) that requires an authenticator to verify the presence of a human being at the client device attempting to authenticate to a site. While the FIDO protocol mandates the TUP, it leaves the TUP’s implementation up to manufacturers of authenticators so the market may innovate and provide a variety of solutions. Some external authenticators merely require you to touch a metallic sensor (generally, with a blinking light-emitting diode) on the device to prove TUP. While this implementation does not identify a specific user, it provides the RP evidence of possession of the right authenticator containing a private key corresponding to the registered public key at the RP site, as well as the presence of a human being at the client device with that authenticator. The design of the FIDO protocol takes into account that platforms prevent attackers from gaining access to lower-level communication protocols—such as the universal serial bus (USB), near-field communications (NFC) or the Bluetooth low energy (BLE) transport protocols—between the platform and an external authenticator.
• Where RP sites require the authenticator to verify the identity of the user at the client device, FIDO supports the use of embedded device authentication capabilities to support user verification (UV). An external authenticator with biometric capabilities; the MacBook with TouchID; a Windows 10 personal computer with a fingerprint reader; a mobile device with a fingerprint reader, personal identification number (PIN), or a geometric pattern reader—any of these provide assurance to the RP application that the FIDO authenticator verified the identity of the user before authorizing the use of a private key to digitally sign the FIDO challenge. In keeping with privacy principles of the FIDO protocol, neither the biometric template, nor the PIN/pattern are shared with the RP site—they are used only to verify the user identity locally on the authenticator device/platform, and when verified, unlock the private key to sign the FIDO challenge.
• FIDO protocol can require that assertions—digital signatures generated during the FIDO authentication process—cannot be replayed by requiring the FIDO server to send a unique nonce (monotonically incrementing number used once) as part of the challenge, and having the authenticator sign the nonce with the private key. The FIDO server not only verifies the digital signature in the assertion, but also verifies the accuracy of the nonce with what the server sent earlier, and that the nonce was not used in any prior authentication.
• With the appropriate platform and authenticator, FIDO has the potential to deliver a frictionless user experience for a business transaction. For instance, a transaction performed on a device with a fingerprint reader could render transaction details to the user and prompt for a FIDO digital signature asserting to the transaction details. This obviates the need to send any short message service (SMS)-based OTP to the user’s mobile phone or to e-mail an OTP. This is also true of mobile devices. This frictionless experience can have a profoundly positive experience with users while drastically reducing risk for an RP due to the security of the FIDO protocol.

FIDO is one of the most innovative authentication solutions that has appeared on the landscape in a quarter of a century. NIST declared FIDO to provide the “highest assurance level” for an authentication protocol in its Special Publication 800-63vi. While it still remains the responsibility of users and/or RPs to ensure that Authenticators are secure enough for their purposes, FIDO Alliance has defined a security certification process conceptually analogous to the Federal Information Processing Standards (FIPS) 140-2, but whose tests are specific to features defined within the FIDO protocol. Manufacturers of Authenticators may choose to submit their devices to independent laboratories to test them for specific security levels, then provide the FIDO Alliance results for certification. With configurable FIDO servers, RPs may define security policies that are suitable for their business purposes.

There are dozens of implementations of FIDO® Certified Authenticators and servers, including StrongKey’s open-source FIDO® Certified server. If you have a recent build of Windows 10 on your computer, a MacBook with TouchID, an Android 7 (or greater) phone, or an iPhone with the latest build of Safari, we encourage you to try the experience of registering and using a FIDO authenticator at sites where they are currently supported—FIDO is certain to play a central role in your security defense strategy in the coming decade.