A look at the recently released YubiKey 5 hardware
authenticator series and how web authentication with the new
WebAuthn API leverages devices like the YubiKey for painless website
registration and strong user authentication.
I covered the YubiKey 4 in the May 2016 issue of Linux Journal, and
the magazine has published a number of other articles on both YubiKeys
and other forms of multi-factor authentication since then.
Yubico recently has introduced the YubiKey 5 line of products. In addition to the
YubiKey’s long-time support of multiple security protocols, the most
interesting feature is the product’s new support for FIDO2 and WebAuthn.
WebAuthn is an application programming interface (API) for web
authentication. It uses cryptographic “authenticators”, such as a YubiKey
5 hardware token to authenticate users, in addition to (or even instead
of) a typical user name/password combination. WebAuthn is currently a
World Wide Web Consortium (W3C) candidate recommendation, and it’s already
implemented by major browsers like Chrome and Firefox.
This article provides an overview of the YubiKey 5 series, and then
goes into detail about how the WebAuthn API works. I also look at
how hardware tokens, such as the YubiKey 5 series, hide the complexity of
WebAuthn from users. My goal is to demonstrate how easy it is to use a
YubiKey to register and authenticate with a website without having to
worry about the underlying WebAuthn API.
About the YubiKey 5 Series
The YubiKey 5 series supports a broad range of two-factor and
multi-factor authentication protocols, including:
- Challenge-response (HMAC-SHA1 and Yubico OTP).
- Client to Authenticator Protocol (CTAP).
- FIDO Universal 2nd-Factor authentication (U2F).
- Open Authorization, HMAC-Based One-Time Password (OATH-HOTP).
- Open Authorization, Time-Based One-Time Password (OATH-TOTP).
- Personal Identity Verification (PIV).
- Web Authentication (WebAuthn).
- Yubico One-Time Password (OTP).
In addition, the entire YubiKey 5 series (with the exception of the
U2F/FIDO2-only Security Key model) now supports OpenPGP public key
cryptography with RSA key sizes up to 4096 bits. This is a notable bump
from the key sizes supported by some earlier models. Yubico’s OpenPGP
support also includes an additional slot for an OpenPGP authentication
key for use within an SSH-compatible agent, such as GnuPG’s
Figure 1. YubiKey 5 Series
You can create OpenPGP keys on your computer and then move them into the
YubiKey, or you can create them directly on the key itself for extra security.
On-key generation of crypto keys ensures that secret keys never
are exposed to a host computer. This provides the ability to sign and
decrypt data in relative safety, even when attached to systems that
shouldn’t be trusted with secret key material.
The YubiKey 5 series is also notable for its broad array of form
factors, including USB-A, USB-C and low-profile “nano” devices that can
be left in a port indefinitely. A number of form factors also support
Near-Field Communication (NFC) for use with tablets and mobile phones.
Figure 2. YubiKey 5 with NFC
The YubiKey 5 series also includes a low-cost model (aptly named the
“Security Key”) in a USB-A form factor. The Security Key provides only
U2F and FIDO2 authentication. This model is currently less than half the
cost of its more capable brethren in the series. If you don’t need the
other features or form factors and just want to make use of WebAuthn
web authentication, this model is a great place to start.
Figure 3. Security Key by Yubico
What’s WebAuthn All About?
Two-factor authentication (2FA) is something everyone likely is becoming increasingly
familiar with. In security, authentication requires one or more of the
- Something you know, like a password.
Something you have, like a cryptographic token or officially issued ID
Something you are, like a person with a specific fingerprint or retinal
The user name and password combination is the “something you know” type
of authentication. Many websites and services now provide users with
better security through a second factor. This is typically a one-time
password service via Short Message Service (SMS), single-use Time-Based
One-Time Password (TOTP) tokens through Google Authenticator or similar
applications, push-based TOTP tokens from Duo or LastPass integration,
or U2F challenge/response authentication.
U2F is most notably used by Google services, and until quite recently, it
has been limited to users with a recent Chrome browser. From a security
perspective, U2F and other 2FA techniques are useful tools for
increasing web application security. However, there’s a growing need for
a more seamless user experience, and an ever-increasing need for more
robust authentication protocols. As part of an evolving W3C draft
standard, WebAuthn provides a better user experience (and arguably a
stronger approach to identification and authorization) when using
compliant authenticators, such as the YubiKey token.
WebAuthn is designed to be backward-compatible with devices built for
the earlier FIDO U2F standard. This includes hardware tokens such as the
YubiKey 4, Google’s Titan key and various U2F-only devices. However,
unlike the YubiKey 5 series, many U2F devices are limited to providing
only a hardware-based second factor and aren’t designed for the full
suite of multi-factor capabilities provided for by WebAuthn.
As an API, WebAuthn is fundamentally a set of protocols that interacts
with CTAP-enabled devices like the YubiKey 5 to provide a comprehensive
suite of authentication services that rely on public key cryptography.
Depending on the capabilities of both the server and the user’s device,
WebAuthn supports the following:
passwordless logins, where the presence of the hardware token is
sufficient. This is somewhat similar to passwordless SSH keys, only much
more secure. A physical YubiKey token won’t expose secret key material
to the local or remote host systems even when plugged in, and it can’t be
used at all when physically removed.
Two-factor authentication (2FA):
this is typically a user name and password combination (something you
know), followed by detection of the hardware token (something you have).
This type of 2FA is generally considered more secure than second-factor
authentication systems, such as SMS, TOTP or HOTP generators, because of
the requirement for a physical token.
Multi-factor authentication (MFA):
true MFA often involves a PIN or biometric signature that isn’t
transmitted over the network. This third factor is typically used
locally to unlock the functionality of the hardware token, and it adds
another “something you know” or “something you are” layer for successful
Google Authenticator and Alternatives
Although proprietary systems, such as RSA’s SecurID solutions, have been
around a long time, the past decade has seen the rise of many
alternatives for second-factor authentication. Today’s users are likely
familiar with SMS solutions that send a six-digit code to their cell
phone, but other types of client-side software and hardware tokens have
been increasingly on the rise since 2003.
Google Authenticator, initially released in 2010, is arguably the most
well known software token solution for typical web users. Google
Authenticator leverages a number of open (if not necessarily
open-source) protocols, including the widely used QR barcode symbology.
Scanning the QR code imports a software token into the user’s smartphone, populating a client-side code generator on the device.
Common alternatives to Google Authenticator include:
FreeOTP (notable for being open-sourced by Red Hat and available under an
Apache 2.0 license on GitHub).
- Authy (notable for providing multi-device capabilities).
- LastPass Authenticator.
- Microsoft Authenticator.
- Duo Mobile.
There are certainly many, many others, each with its own set of pros,
cons and specialized use cases. This relatively small handful
represents the bulk of mind-share among typical users, but you can
definitely consider additional alternatives based on issues of cost, open
standards support and security track record.
WebAuthn, Overly Simplified
The current working draft of the WebAuthn specification is more than 100
pages long, so describing it in simple terms runs the risk of
over-simplification. With that in mind, this section is not a
comprehensive guide to the entire WebAuthn API. It’s intended to be a
useful abstraction that highlights how WebAuthn works behind the
scenes, highlighting the value of the YubiKey in simplifying the web
registration and authentication process.
The heart of WebAuthn is the challenge/response that takes place between
a “relying party server” (aka the remote service, such as a website)
and a token in the user’s possession. The server issues a challenge that
is ultimately received by your browser, which then interacts with the
YubiKey or another U2F- or FIDO2-compliant token. This token is called
With a hardware token like the YubiKey, the authenticator can create
a signed response to the server’s challenge without ever exposing the
secret key portion of the credentials stored within the token. The
server then validates the response from the authenticator to complete
the registration or authentication process.
Even with software tokens, as opposed to hardware tokens like the
YubiKey, the API is designed to limit the amount of data exposed to the
server during token registration or authentication. Although hardware
tokens are considered more secure, the WebAuthn API allows for other
types of authenticators as well.
With WebAuthn, the user experience involves just a few simple steps:
- Receive an authentication prompt from your browser.
- Use your YubiKey to provide a response.
Wait a few milliseconds for the WebAuthn framework to validate your YubiKey’s
- Do fun stuff as an authenticated user!
Under the hood though, WebAuthn and the YubiKey are doing a lot more
work. Let’s take a closer look.
The Not-So-Simple WebAuthn API
Although the user experience is straightforward, the implementation details
are anything but. The WebAuthn API covers two closely related key-management activities for handling registration and authentication, and
it calls these activities “ceremonies”.
Both ceremonies require a Relying-Party Server, a Relying-Party
with certain properties.
Currently, supported web browsers include:
- Mozilla Firefox 60+.
- Google Chrome 67+.
- Google Chrome for Android Beta 70+.
Support by Microsoft Edge was introduced into development builds in July
2018. Meanwhile, Apple is a participant in the WebAuthn working
group, but there is no indication of if (or when) the Safari browser
will support the WebAuthn API.
Authenticator properties include key management capabilities and the
ability to generate cryptographic signatures. FIDO2 authenticators must
also be able to map credentials to each 64-byte user handle associated
with a given Relying Party, although the underlying implementation
details may vary. Since the YubiKey 5 documentation states that it
supports “unlimited” credentials, I assume that the mapping is
derived from input during the WebAuthn ceremonies, rather than using
fixed storage space within the YubiKey token.
Protocol and implementation details related to how the Authenticator
Attestation Globally Unique Identifier (AAGUID) is tied to individual
tokens without creating privacy concerns, and how attestation of
authenticator provenance is handled by X.509 certificates, are certainly
important for the security of the WebAuthn system. But while these
concerns are addressed within the specification, the average user
doesn’t actually need that level of technical detail to use a
YubiKey 5 device safely. The elegance of the WebAuthn/YubiKey solution is that
the API handles those details for you.
Registration Using the WebAuthn API
Before you can use a YubiKey to authenticate to a web service, a U2F- or
FIDO2-capable device must register with the relying party server
through a registration ceremony. There are some potential use cases
where registration is optional or when first-time registration is
combined with authentication for new enrollments. However, a typical website
likely will want to associate a given credential with a user
handle, which is a 64-byte identifier for a user account.
At the time of this writing, the registration ceremony defined by the
API follows seven steps (Figure 4):
Registration request: the server-side application initiates a registration request. How this
is done is not specified by the WebAuthn API. This is currently an
application-specific implementation detail.
the server sends a challenge, along with user information and
Browser requests credential from authenticator:
the user’s browser provides sufficient information to an authenticator
so the device can generate a unique credential. The YubiKey 5 includes
the server-generated user handle when generating a new credential, while
older YubiKeys or other U2F-only devices will create a credential with
userHandleset to null for backward-compatibility.
Authenticator creates an attestation:
the YubiKey creates a cryptographic key pair for the credential and
bundles the public key inside a special message called an “attestation
Authenticator sends attestation object to browser:
the YubiKey signs the attestation statement with a verifiable digital
signature and passes the statement along with other data back to the
browser as an “attestationObject”.
Credential passed to relying party:
some JSON and encoded data, and sends it back to the relying party
Server as an “AuthenticatorAttestationResponse”.
Server validates response:
the server then validates the response and the credential’s digital
signature. If all the validations succeed, the server completes the
registration process by associating the public key in the attestation
with the user’s account. This public key can then be used for immediate
or future authentication.
Figure 4. WebAuthn Registration Flow (“Web Authentication: An API for
accessing Public Key Credentials Level 1.” W3C Candidate Recommendation, 7
August 2018. https://www.w3.org/TR/webauthn/#web-authentication-api)
To be quite frank, even this “deep dive” into the registration process
glosses over a great deal of cryptography and message-passing. However,
the beauty of WebAuthn, especially when paired with a YubiKey, is that
all of this cryptographic work and interprocess communication is
essentially invisible to end users. In actual use, basic registration
simply involves inserting a YubiKey in response to a browser prompt and
tapping the touch-sensitive part of the YubiKey (which varies by model)
to activate it.
Once the authenticator is registered, you’re only halfway done. You’ve
registered a WebAuthn credential using a YubiKey, but you still have to
present the newly registered credentials to the website before you’re
actually authorized. In practice, websites can present registration and
authentication as a seemingly unified process from the user’s point of
view, but they’re actually different ceremonies within the WebAuthn API.
Authentication with the WebAuthn API
The process for authentication is actually quite similar in its outlines
to the registration process. Although protocols and messages may vary, the
key difference is that the relying party server and the authenticator
are validating an existing credential that was created during the
registration process described above.
Figure 5. WebAuthn Authentication Flow
(“Web Authentication: An API for accessing Public Key Credentials Level 1.”
W3C Candidate Recommendation, 7 August 2018. https://www.w3.org/TR/webauthn/#web-authentication-api)
As with registration, the user perspective is simply to insert the
YubiKey and trigger it with a touch. What could be easier?
Passwordless Login Example
If you have a YubiKey device that supports U2F or FIDO2, you can test
out registration and authentication using a number of publicly available
testing services. For this set of examples, let’s use the site provided
by Duo Security for YubiKey testing.
Launch your browser, and navigate to https://webauthn.io. Next,
register your YubiKey by entering a unique user name. As many other users
are likely testing their keys too, I recommend using a UUID for your
user name. Running the
uuidgen command, available on most Linux and
macOS systems, will print a value that is sufficiently random for this
For this exercise, leave the other values, such as Attestation Type and
Authenticator Type, at their defaults.
Figure 6. Register Credential
After you’ve entered your user name, click Register a User/Credential.
You’ll then be prompted to tap your YubiKey to complete the
Figure 7. Tap YubiKey
Note that this particular application shows two different dialog boxes.
Other WebAuthn sites show only the top modal dialog; the second (and
admittedly prettier) dialog seems to be unique to the Duo website.
In any case, once you’ve tapped your YubiKey, you’ll be registered and
logged in immediately. You’ll see a screen similar to the one shown in Figure
Figure 8. Registered and Logged In
If you return to the home page, you’ll again see the login screen. To
test that your YubiKey is working properly, enter your user name and then
click Login with Credential. No password required!
Although this example seems trivial, it highlights how easy it is for a
user to register or authenticate with a YubiKey. Even though the
underlying implementation is complex, the user experience is smooth
When properly implemented, WebAuthn and compliant tokens like the
YubiKey robustly guard user privacy while providing strong user
authentication features. Sections of the standard address ways to
prevent data correlation, de-anonymization and the use of credentials
without user consent.
A full examination of WebAuthn privacy issues is outside the scope of
this article, but section 14 of the standard is titled “Privacy
Considerations”. If you’re an IT auditor, security administrator,
security engineer or application programmer, section 14 will be
useful to you.
In late August 2018, security researchers from Paragon
Initiative Enterprises raised concerns about the WebAuthn API’s use of
certain algorithms, specifically Elliptic Curve Direct Anonymous
Attestation (ECDAA) and RSA with PKCS1v1.5 padding. ZDNet picked up the
story and added some additional clarification.
The short version for non-cryptographers is that certain algorithms in
the standard represent potential weaknesses. These weaknesses are not
currently easy to exploit in practice, but they may present problems for the
future. The researchers’ cautions are aimed more at API implementers
than users, with the goal of improving the WebAuthn standards before
they’re finalized. The researchers themselves say:
WebAuthn and ECDAA are not doomed. Don’t throw away your hardware
tokens, revert your codebases to use SMS or TOTP, or any other such
>> Source Link