Designed for securing online accounts, FIDO U2F as a protocol and YubiKey as a hardware tool are not silver bullets. If not used wisely, this powerful combo becomes an attractive target in the hands of skilful attackers.
In this post, we will explore some of the hidden pitfalls, typical mistakes, and concerns that system architects and software developers should be aware of when building authentication systems using YubiKeys.
- Why use YubiKey
- Yubikey: Architecture and capabilities
- FIDO family of authentication protocols: FIDO U2F, FIDO2 (passwordless)
- Using YubiKeys in FIDO U2F
- YubiKeys in FIDO U2F: Security issues
- Building secure authentication with FIDO U2F and YubiKey
- Conclusion
Why use YubiKey #
YubiKeys are physical security devices that help protect user accounts. These kinds of devices are often referred to as a hardware security key or hardware token. They support a variety of cryptographic applications and standards. They are often used as an additional layer of security for online accounts and systems by enabling two-factor authentication (2FA) or multi-factor authentication (MFA).
YubiKeys as MFA: User identification and phishing prevention #
NIST SP 800-63b recognizes hardware tokens, such as smart cards or USB security keys like YubiKey, as a strong form of MFA. These tokens fall under the category of “possession factors” because they are something a user has.
YubiKey makes it harder for attackers to reuse credentials obtained from phishing by introducing a second factor of authentication that is difficult to spoof due to a challenge-response mechanism.
Why use a hardware token for a multi-factor authentication:
- Increased security: MFA provides higher security guarantees than one factor authentication. Hardware tokens are less vulnerable to compromise, and can withstand a wider range of threats compared to passwords.
- Authenticator Assurance Level: Indicate the required strength of authentication for specific applications or systems. Hardware tokens are often recommended for higher AALs, such as AAL3 for systems with elevated security requirements.
- Compatibility: Hardware tokens are designed to work seamlessly with various operating systems that support standards FIDO U2F and FIDO2, including Windows, macOS, Linux, Android, and iOS, and large online platforms like Google, Apple, AWS, Azure.
- Portability: Hardware tokens are small and lightweight.
- Extensibility: Hardware tokens support multiple protocols and can be used in a variety of ways via USB, NFC, and Bluetooth. This makes them highly extensible for building and securing custom authentication and identity management solutions.
- Relying on cryptography: Hardware tokens rely on cryptography for protecting sensitive data and advanced physical security measures to protect the stored keys.
Yubikey: Architecture and capabilities #
The YubiKey architecture is designed to provide a high level of security and to be compatible with a wide range of devices and applications. On a base level, YubiKey is a microcomputer that supports multiple transport protocols. It has a tamper resistant secure element (cryptographic coprocessor) that can store a limited amount of data and perform cryptographic operations.
YubiKey: Supported applets #
The YubiKey firmware provides multiple “applets”— small applications that implement various security routines. The Yubikey 5 series has a number of them, like FIDO U2F, FIDO2, OATH, PIV, and others. Each application has its own configuration and data, like PINs and keys. Such a variety of supported algorithms makes YubiKey a swiss knife for building authentication protocols.
YubiKey: Supported cryptographic operations #
The YubiKey supports a variety of cryptographic operations: Digital signatures, public key encryption, one-time passwords and challenge-response authentication. Some of the algorithms are implemented as parts of the larger protocols (challenge signing in FIDO U2F), but others are accessible as standalone operations (like signing and encryption in PIV or OpenPGP applets).
These algorithms can be combined in unexpected ways. For example, you can use HMAC-SHA1 mode to derive the encryption key for your password manager or even a whole drive.
Struggling with building secure and user friendly software?
Get assistance from our security engineers.
FIDO family of authentication protocols: FIDO U2F, FIDO2 (passwordless) #
The FIDO family of authentication protocols is a set of open standards, designed to improve the security and convenience of online authentication. The two most well-known FIDO protocols are FIDO U2F and FIDO2.
The FIDO2 protocol is an evolution of FIDO U2F, designed to address some of its limitations. For instance, FIDO U2F can be used only as a second factor, while FIDO2 can be used as the main authentication method, thus eliminating the need to remember and type password.
FIDO terms #
The terminology around FIDO authentication methods can be quite overwhelming. So, to (hopefully) reduce the amount of confusion we will go through the terms and their relations:
- FIDO (Fast Identity Online): A set of open standards, enabling passwordless authentication for both mobile and desktop applications through portable devices.
- FIDO U2F: A protocol for secure 2nd factor authentication.
- FIDO2: A set of protocols designed to replace traditional username & password authentication. It contains WebAuthN and CTAP.
- WebAuthn: A web standard that enables passwordless authentication in web browsers. It dictates the browser API that relying parties should use to interact with the authenticator.
- CTAP1/CTAP2 (Client-to-Authenticator Protocol): Protocols for communication between the client and a FIDO authenticator. CTAP1 is a protocol for FIDO U2F, while CTAP2 is for FIDO2.
- W3C (World Wide Web Consortium): An international community that develops web standards and specifications. In the context of FIDO, the W3C helps standardising technologies like WebAuthN.
- Passkeys: Most often it means discoverable FIDO2 credentials.
Two-factor authentication in FIDO U2F #
We are going to briefly outline how FIDO U2F works. There are 3 parties in the protocol:
- FIDO authenticator: Hardware token that generates an asymmetric keypair and issues cryptographic signatures.
- FIDO client: Often a browser that relays and verifies messages between the authenticator and the relying party.
- Relying Party: The service that the user wants to access. Note that in reality there could be multiple services that authenticate users and verify tokens authenticity.
FIDO U2F can only be used as a second factor, as the service must already know the user’s identity before initiating authentication.
FIDO U2F uses a hardware token to generate cryptographic signatures for authentication. During registration, the user generates a keypair and sends the public key to the service. Then, during the authentication process, the service sends a challenge to the user, who signs it with the token and sends the signature back to the service. The service verifies the signature with the user’s public key.
ImperialViolet—From U2F to passkeys provides an excellent technical description and allows one to dive into the history of the FIDO protocols.
FIDO U2F security strengths #
Let us identify the strengths and weaknesses of FIDO U2F starting with pros:
- Public-key cryptography: No secret data appears in plaintext in transit.
- Counter-based cloning detection: The hardware token increments the counter after each authentication and sends it to the relying party.
- Private key never leaves device: The private key is created within the token’s secure hardware, preventing it from being extracted.
- Prevents replay attacks as the protocol uses challenge-response authentication.
- Prevents phishing by blending the origin (URI) to the signature.
- Prevents MitM with TLS Channel ID binding, but it’s optional.
- Prevents passive tracking of hardware tokens across different accounts, as each registration is assigned a unique key handle.
- Uses attestation certificates to verify the token’s authenticity.
- Wide adoption: Already supported on most platforms (operating systems, Web browsers) with multiple interfaces (USB, NFC, etc).
FIDO U2F security weaknesses #
- Weak default verification: While U2F offers several options for the “user verification”, the protocol does not require them for authentication and registration. Instead, most typically, the verification of a simple “user presence” is used (meaning it’s enough to just press a button on hardware token instead of entering the passcode).
- Limited fallback options for cases when users lose their hardware tokens. Handling device lost requires additional work on the authentication system side.
- Remember me: Using login and password durign authentication process is still mandatory. Thus web services often implement the “remember me” feature, which comes with its own risks.
- Uneven adoption: The software stack of the standard is complex, the supported features and implementation quality of the FIDO U2F software vary for different platforms and applications.
- Not used features: While protocol offers varios useful security features, developers tend to ignore many of them, such as authentication counters are generally not used.
- Users responsibility: Users are responsible for managing their hardware tokens in a secure way which they rarely do.
Using YubiKeys in FIDO U2F #
YubiKey-based FIDO U2F solutions offer a number of security and convenience benefits over traditional password-based word is missing here. As analysed in the Please Remember Me paper, the U2F remains secure in the following scenarios:
- Resilient to physical observation: The authentication process is not vulnerable to the “over the shoulder” attacks.
- Resilient to input observation: In the same manner, capturing user input with a key logger is not enough to steal the user’s identity.
- Resilient to communication observation: Passive eavesdropping doesn’t leak information that can be used by the adversary (this includes web and token communication).
- Resilient to leaks: Even if data stored by the relying party is compromised, it cannot be used to login into the user’s account in the same relying party.
- Resilient to leaks from other verifiers: Security breach of one relying party cannot be used to compromise users on other relying parties.
- Resilient to phishing: Relying party’s spoofing cannot be used to impersonate a user (with some conditions, more on this in the next section).
- Long term resilient to theft: If an attacker steals user credentials and a FIDO U2F token, a user can revoke the token. However, there is a time window where an attacker can use the token to impersonate the user.
- Unlinkable: Even if two or more relying parties collude, they cannot verify whether a single user authenticates to both of them with the same token.
YubiKeys in FIDO U2F: Security issues #
Over the years, researchers have discovered a number of flaws in both the protocol design and its practical implementations which we will look at in the section.
The U2F protocol is supported by all major platforms: Operating systems (desktop and mobile), and browsers (also desktop and mobile). However, as it often happens, in such a zoo of platforms there could be deviations, incompatibilities, and bugs.
Yubico offers a useful page with support matrices for FIDO U2F and FIDO2 where you can discover additional information. The number of asterisks varies due to platform differences. Some gadgets require a PIN code for authentication, while others do not and may have limitations on their NFC or USB functionality.
As a result, integrating hardware tokens into your system is not an easy task and requires intensive testing on all your supported platforms.
Attacks against FIDO U2F and YubiKey #
FIDO U2F as the protocol and YubiKeys as device face potential security threats, so we’ll introduce you to the most remarkable attacks and flaws to consider.
1. YubiKey attack: Mis-binding during the credential registration #
The adversary that has access to the user’s FIDO client (like malicious browser extension) replaces the victim’s public key and signatures with their own. As a result, the relying party registers the attacker’s authenticator instead of the victim’s. This attack becomes considerably easier when the relying party does not verify the device’s authenticity. In this case an adversary can employ software based tokens instead of creating a laboratory with real hardware tokens.
2. YubiKey attack: Double-binding during the protocol execution #
The same adversary registers their malicious authenticator when a user executes the U2F protocol (either during registration or login), sending a second registration request in the background to register the adversary’s authenticator to the same account.
To address the attack, the relying party should notify users when a new device is registered and include enough information to distinguish between user tokens. Also, it’s advisable to require additional authentication from the already registered tokens before registering a second one.
3. YubiKey attack: Key disclosure #
Aims to disclose or manipulate key material stored on the victim’s authenticator. While this is something that hardware tokens should prevent, in practice it’s sometimes possible because of side channel leaks.
Monitoring such attacks to increase user awareness can help them quickly react and replace vulnerable tokens. In addition, general user education on secure token management practices will always be relevant.
4. YubiKey attack: Person in the middle (MitM) #
MitM is an attack where malicious actors try to sneak in and interfere with the authentication process. They can intercept a victim’s authentication request, substituting it with their own. The malicious request is signed by the victim’s authenticator and returned to the relying party. The attacker records the response and uses it to get access to the victim’s account.
The U2F protocol already contains a mechanism for preventing such an attack using TLS token binding. However, it was not standardised when U2F came out and, as of today, most browsers either don’t support it or have non-standard implementation.
This attack requires more resources and cost compared to phishing, so fortunately it’s not that straightforward.
Advice: Notify a user about every login attempt and provide information on each session.
5. YubiKey attack: Supply chain #
As with any 3rd party solution, there always exist supply chain risks—no one is 100% protected. We all are humans so even the finest of us fail. Nevertheless, it’s important to be ready for such scenarios.
Stay responsible and always monitor recent vulnerabilities and security incidents in your supply chain: from browsers to software libraries, from hardware tokens to mobile phones. Install firmware and software updates where it’s possible and educate users.
6. YubiKey attack: Others #
There is still a wide range of potential attacks that require further investigation. A well-grounded research by Tarun Kumar Yadav and Kent Seamons “A Security and Usability Analysis of Local Attacks Against FIDO2” provides a detailed overview of these attacks and the ones mentioned above.
Building secure authentication with FIDO U2F and YubiKey #
When relying on FIDO U2F and YubiKey to build secure authentication, there are some important issues to keep in mind for using the YubiKey FIDO U2F:
U2F doesn’t protect users from password exposure: For instance, the user can be redirected to a phishing site where they reveal their password. The phishing attempt will be detected at the stage of U2F authentication.
U2F is not resistant to device theft: The stolen U2F device can be used by an attacker if U2F protocol requires only a “test of user presence” for registration and authentication operations. In this case, the verification of the U2F device holder is not provided. However, with the YubiKey, there is the option to specify a PIN for user verification.
Users are responsible for backing up their device to be able to authenticate in case the main device is lost. For example, users should be able to register at least two U2F devices with every service provider. Implementing other fallback methods securely should be properly designed and analysed.
YubiKey uses a global (i.e., shared between credentials) signature counter that gets incremented upon each authentication. If the signature counter ever decrements, the U2F device should be considered compromised, in which case the relying party should lock the user’s account.
The U2F protocol does not specify challenge expiration explicitly. Still, limiting the lifespan of the challenges to a couple of minutes is a good idea.
During registration, the U2F device sends an attestation certificate to the relying party. The certificate is loaded by the vendor when the device is manufactured. The only way to reliably verify the authenticity of the U2F device is to verify the validity of the attestation certificate (including mandatory verification of all intermediate certificates up to the root certificate). Major services don’t do this which makes MitM attacks during registration easier.
Do not let users bypass the U2F step during the authentication process.
Security engineering is an art. Let's create together.
Conclusion #
Using such complex protocols as FIDO U2F and hardware tokens as YubiKey requires deep understanding and a wise approach. The engineers are to be constantly focused to avoid mistakes and apply the best practices to reach the final goal. These instruments are designed for protection of user identities and decreases chances of authentication compromise.
The U2F protocol is complex and has many moving parts that are easy to get wrong. Your system does not become secure automatically simply because it uses FIDO U2F. Even you send the users the latest YubiKey tokens.
Please note that no matter how advanced the FIDO protocol family is, it requires a sharp mind and the skilful hands of those implementing it. As there are no 100% secure systems—these are just effective tools in human hands that require proper configuration, attention and smart application.
If you’re tackling intricate software and hardware challenges and could use some cybersecurity expertise, don’t hesitate to reach out.