Incidents caused by passwords, such as unauthorized money transfers and account takeovers, show no sign of stopping. While an ideal world would allow anyone—including the elderly and those with limited tech literacy—to manage their online accounts easily and securely, the history of the internet has arguably proven that creating a passwordless world is the foremost priority. And now, FIDO (Fast IDentity Online) is drawing attention as the technology to make passwordless login a reality. Bringing FIDO to the browser is WebAuthn (Web Authentication). Based on media reports and the like, some people might think these are simply about fingerprint authentication, but that is not quite the case.

There are already numerous articles on WebAuthn, so I will leave the technical how-tos to them and focus in this article on the bigger picture—the grand vision of how this technology will reshape the future of digital identity.

Authentication Fundamentals #

To understand the concepts behind FIDO, we must first cover the fundamentals of authentication.

The Three Factors of Authentication #

Whether online or offline, there are generally considered to be three main factors used to verify a person's identity:

  • Knowledge: Something only the user knows, such as a password or security question.
  • Possession: Something only the user has, such as a security key or a specific device.
  • Biometrics: Something unique to the user, such as fingerprints, irises, veins, or facial features.

For example, at a bank ATM, identity is verified using two factors: having the card itself (possession) and knowing the PIN (knowledge). Similarly, with a chip-enabled credit card, inserting the card into a terminal instead of signing and entering the correct PIN constitutes two-factor authentication satisfying both possession and knowledge.

However, these are offline scenarios; online authentication across the internet on computers and smartphones has historically been a different story. In an entirely online system, proving that you possess something was difficult, and the infrastructure for reading biometrics wasn't in place. As a result, for a long time, knowledge-based authentication—typified by passwords—was used almost exclusively.

But because passwords exist online, they have always been inherently vulnerable to risks—automated brute-force login attempts, anonymous data theft via traps and phishing, or simple guessing. It is fair to say that both users and service providers have struggled to handle passwords securely without fully understanding best practices.

OTP and Its Weaknesses #

That is why combining passwords with OTPs (One-Time Passwords) has gained popularity in recent years. After entering a password, the user enters a code sent via SMS or displayed on an app or dedicated device. Because the same code is not displayed to anyone else, this increases security.

However, OTPs have a weakness: if intercepted, a third party can use them. For example, if a user falls for a phishing site (a fraudulent site that looks identical to the real one but has a different URL) and enters their password and OTP, their account can be hijacked without them even realizing it.

Consequently, multi-factor authentication using security keys has grown popular recently, especially in enterprise environments. This achieves two-factor authentication by combining the user's security key as possession authentication with a password.

Public-Key Cryptography and Security Keys #

Proving possession using a security key is accomplished via public-key cryptography, a concept familiar to engineers through tools like SSH.

With passwords, the same string is stored in some form both in the user's head and on the server, meaning that if either is compromised, the account is at risk of being hijacked. With public-key cryptography, however, different keys are kept on each side: a private key on the user's side and a public key on the server's side.

The fascinating property here is that the private key can issue a "signature" that can only be generated by that private key and verified by the paired public key. When the server sends a random string called a challenge, the user signs it using the private key and sends it back. The server, holding the paired public key, can verify that signature to confirm that the challenge was returned by the legitimate user.

Here is the general flow:

  1. Registration (one-time only): The user creates a public-key pair, securely stores the private key, and sends the public key to the server.
  2. Login: The user receives a challenge from the server, signs it using the private key, and sends it back. The server verifies the signature and challenge using the public key, and grants access once the user's identity is verified.

Using public-key cryptography, the key pair is created specifically for that user and service pair, so even if an attacker intercepts a signature through phishing, it cannot be reused. Furthermore, even if the server is compromised and the public key leaks, it cannot be used to impersonate the user's account. As long as users protect their private key, the risk of takeover is extremely low, and they can authenticate by proving possession (User Presence = UP).

That said, expecting users with limited technical literacy to securely store their private keys without ever leaking them is easier said than done.

To make this entire process accessible to anyone, a mechanism was invented using dedicated devices called security keys. In a broader sense, they are referred to as "authenticators." An authenticator has specialized capabilities for authentication: during registration, it creates a new key pair, securely stores the private key, and returns only the public key; during login, it generates and returns a signature.

Standardization Through FIDO #

As great as authenticators are, widespread adoption cannot be expected if the mechanisms differ across PCs, smartphones, OSes, and platforms. This is where standardization by an organization called the FIDO Alliance comes in. The FIDO Alliance defined CTAP (Client to Authenticator Protocol) for communication between devices and authenticators, UAF (Universal Authentication Framework) for biometric verification, and U2F (Universal Second Factor) for two-factor authentication. These specifications have been implemented and used across multiple platforms.

For instance, UAF brought biometric authentication to NTT DOCOMO mobile devices. In desktop Google Chrome, while not originally implemented as a native browser feature, a built-in extension enables USB U2F security keys via a JavaScript API. Furthermore, by installing the Google Authenticator app, Google Chrome on Android can similarly use NFC-enabled U2F security keys. Firefox also supports U2F security keys behind a flag. This U2F-based two-factor authentication is already available on services like Google, Dropbox, and Facebook.

And On to FIDO2 #

To pursue wider adoption and usability, FIDO later developed an expanded new version: FIDO2. In FIDO2, UAF and U2F were unified, and alongside the CTAP2 protocol for communicating with authenticators, a W3C-based JavaScript API called WebAuthn (Web Authentication) was standardized for interacting with authenticators from browsers. It is already implemented in Google Chrome, Mozilla Firefox, and Microsoft Edge, and Apple Safari's implementation is well underway.

Beyond having a refined specification, FIDO2 is expected to see widespread adoption because its standard implementation across browsers and platforms makes it easily accessible to general developers.

FIDO2 and Authenticators #

An often overlooked aspect when understanding FIDO2 is the characteristics of authenticators. While many people know that fingerprint authentication can be used with FIDO2 and WebAuthn, quite a few may not be able to explain how that relates to security keys.

Authenticators come in various forms: those supporting U2F, connecting via USB-C, connecting via BLE, embedded in devices like smartphones or PCs, capable of fingerprint authentication, and so on. While it seems complex at first glance, they can be categorized along three criteria:

  • Transport: How the authenticator connects to the device: USB, BLE, NFC, or internal.
  • Attachment: Whether it is directly embedded in a device like a smartphone or PC (platform), or not (cross-platform).
  • User Verification (UV): Whether it includes identity verification capabilities, including biometrics.
A typical security key

For example, the YubiKey 5 Nano can be classified as having USB transport, cross-platform attachment (since it can be removed from the device, even if intended to be left plugged in), and no UV.

The Feitian BioPass FIDO has USB transport, cross-platform attachment (removable), and UV support via fingerprint authentication.

The interesting ones are authenticators with platform attachment. For instance, a Google Pixel 3 can treat the device itself as an authenticator. In this case, transport is internal, attachment is platform, and it supports UV since fingerprint authentication is available.

Most security keys and authenticators currently on the market can be used with FIDO as U2F devices, and because of backward compatibility, they also work with FIDO2. What makes FIDO2 distinctive is the User Verification aspect.

What Is User Verification? #

User Verification refers to the authenticator's capability to verify the user's identity. Identity verification here includes biometric authentication like fingerprint, face, or iris recognition, as well as non-biometric fallbacks like a PIN. In the case of a PIN, verification is done by entering a pre-configured short number or alphanumeric string through a browser or system UI. Authenticators with UV will not issue a signature unless identity verification succeeds. This is the core mechanism behind the promise that FIDO2 eliminates the need for passwords.

In other words, fingerprint-enabled security keys like the aforementioned BioPass FIDO, Android devices with biometric capabilities, Windows devices supporting Windows Hello, and eventually iOS/macOS supporting Touch ID and Face ID, combine possession authentication via public-key cryptography (User Presence = UP) with biometric authentication (User Verification = UV). This achieves two-factor authentication within a single device, paving the way for a completely passwordless login experience.

Not only does it eliminate the risks of passwords, but being able to log in just by touching or looking at your device—isn't that amazing?

The Future Enabled by FIDO2 #

If you have any of the authenticators mentioned above, you can try out a live demo:

https://try-webauthn.appspot.com

webauthndemo.appspot.com

To test a U2F security key, click "Register New Credential" to register, and "Authenticate" to log in (works on Chrome, Firefox, and Edge).

To test built-in biometrics like fingerprint recognition on Android or Touch ID on a MacBook Pro, click "Register Platform Authenticator" to register, and "Authenticate" to log in (as of March 2019, this only works on Chrome). If successful, a dialog will appear in the browser allowing you to test fingerprint authentication or similar methods. "ISUVPAA" stands for "Is User Verifying Platform Authenticator Available," which tells you whether you are using a device with an embedded authenticator (Platform Authenticator) supporting identity verification (User Verification).

Opening the left menu allows you to tweak more detailed parameters individually, though I will skip explaining those here.

A New User Experience: Re-authentication #

One novel user experience enabled by FIDO2 is re-authentication. The idea is that once you log in on a device, subsequent logins on that device can be done with just fingerprint authentication. This experience is already implemented by Yahoo! JAPAN, where re-logging in on the same browser on that device requires only a fingerprint. (Image quoted from the press release)

Yahoo! JAPAN's re-authentication flow

This truly shines in contexts that require high security, such as banking and e-commerce websites. Many banks enforce short session timeouts and require you to log in every time you return, and many shopping sites ask you to re-enter your password at checkout. Being able to authenticate with a fingerprint or face in those moments preserves a seamless user experience without compromising security.

Authenticators Are Bound to Devices #

I mentioned "once you log in on a device," but why is biometric authentication tied to a specific device? You might wonder: if it's the same person with the same fingerprint, why shouldn't you be able to log in directly on a different device?

For security reasons, the biometric data used for authentication is stored exclusively on that device and shielded from network or unauthorized software access. The same applies to the private key, meaning possession authentication cannot simply be used across devices either. In other words, with FIDO2, whenever you switch to a new device, you must somehow log in to the account, generate a new key pair bound to that device, and register your biometrics.

Currently, the most common environments for biometric authentication that come to mind are platform authenticators like Android devices or MacBook Pros, but cross-platform authenticators like the BioPass FIDO also exist. With one of those, you can simply plug the authenticator into any device you want to log into and sign in with your fingerprint anywhere.

However, the vast majority of users will not buy a cross-platform authenticator. Therefore, if you plan to adopt FIDO2, you must consider practical solutions for how these users log in to a new device for the first time. Allowing them to create a password creates an opening for account takeover; thus, for security-minded services, sending a temporary code via email or SMS to let them log in—without creating a password—may become the realistic approach.

Turning Smartphones into Authenticators with caBLE #

Google has proposed a FIDO2 extension called caBLE (cloud assisted BLE). This enables smartphones to serve as BLE cross-platform authenticators. If realized, instead of requiring a dedicated hardware authenticator, the smartphones that most people already carry could be used as authenticators, making passwordless login possible across devices.

In any case, system design will need to account for account recovery from scratch—including scenarios where an authenticator is lost—for the foreseeable future.

Resident Keys #

Another exciting capability proposed in FIDO2 is the Resident Key. Authenticators have internal storage, and whenever a key pair is created during registration with a service, user information is stored alongside metadata about the service.

When logging in without a Resident Key, the user must declare which account they want to log into. With a Resident Key, however, the authenticator can present a list of previously stored accounts, allowing the user to select one, perform biometric verification, and log in.

Mockup of Resident Keys

While not yet implemented in Chrome, this feature is already available in Edge on Windows 10 (the non-Chromium version), and you can take advantage of it using a cross-platform authenticator that supports Resident Keys. Since Windows is primarily a desktop OS, users relying on Windows Hello as a platform authenticator might not feel the benefit immediately. However, if mobile devices like Android phones or iPhones can act as cross-platform authenticators via caBLE in the future, it will enable a world where you carry your identity with you everywhere.

The day may come when your smartphone embodies your identity, letting you navigate the internet without ever hitting the barrier of a login prompt.

What Is Attestation? #

This is getting quite long, but there is one last important topic. Even if FIDO2 provides robust security, it all falls apart if a user is duped into using a counterfeit, malicious authenticator. This is why FIDO2 incorporates a mechanism called Attestation.

Attestation is essentially a certificate embedded in the authenticator, differing per authenticator model (typically not per individual device). Using something akin to a root certificate authority called the MDS (Metadata Service), the server can verify whether this Attestation comes from a legitimately manufactured device. Of course, the FIDO Alliance also offers a certification program that validates authenticators, so using certified authenticators is recommended (Android was recently certified). For more on Attestation, I highly recommend reading this article, which provides an excellent overview.

That said, unless required for compliance purposes (such as in banking, enterprise, or government), requesting Attestation is generally unnecessary. (If you are using them in Google's enterprise environment, please also check out the Security Keys page on the Chromium website.) Furthermore, in an ideal world, a user would only need to carry a single authenticator. If you do use Attestation, leverage the MDS properly to avoid restricting access to only specific device models.

Update: 2019/03/18 I initially noted that Attestation was "not recommended from a privacy perspective," but I have temporarily retracted that statement as it may have been based on a misunderstanding. I will update this once accurate information is confirmed. Update: 2019/03/22 Having confirmed that privacy concerns are essentially non-existent, I have revised the wording above.

Summary #

If you want to experience implementing FIDO2 fingerprint authentication using WebAuthn from a browser, I recommend starting with the codelab created by FIDO evangelist Yuriy Ackermann. His Medium covers not only the browser side but also signature verification and various Attestation verification methods on the server side, so it is well worth a thorough read. Additionally, curated resources compiling documentation, libraries, and demos—including Japanese resources—are extremely helpful:

WebAuthn Awesome

However, if you are thinking about jumping right in and deploying FIDO2 and WebAuthn to production—please exercise some caution. While the documentation and platform support are coming together, the server-side ecosystem is still in an immature stage. Unless your team has exceptional confidence in building cryptographic products, it may not be time to tackle it indiscriminately just yet.

Some developers have already released open-source libraries (the Japanese community's efforts are remarkably active on a global scale), and production use cases like Yahoo! JAPAN are emerging. IDaaS products and FIDO Certified libraries will likely arrive soon. LINE has also announced plans to open-source its own FIDO Certified library within the year.

It won't be too late to roll out FIDO2/WebAuthn to production once more track records, products, and open-source solutions have matured. For now, I encourage you to start by reading the documentation and imagining what kind of future FIDO2 and WebAuthn can enable.

Finally, I would like to thank @herrjemand, @super_reader, @watahani, and @sisidovski for reviewing this article.