Introduction

This blog post attempts to document certain risks when implementing FIDO2/WebAuthn-based YubiKeys and passkeys in enterprise environments and can be applied to high-risk individuals. This content took months of learning, thinking, and discussing with other security engineers due to the nature of these highly nuanced technologies in real-world situations.

Please email me (yawnbox@disobey.net) or Signal me (yawnbox.01) if you have constructive feedback. I'm a security engineer who's professionally worked with these technologies for only 6 months and am still a student who's writing this to continue my journey as an educator. I would have written about this sooner, but it's a very daunting topic to get right, and there's been a number of significant changes in the passkey landscape in the past few months.

If you're interested in hiring me for information security consulting, please email me at c@stellarwind.net. In fact, I'm currently unemployed and would love a full-time job!

Like my other blog posts, this article is licensed as Creative Commons Zero (CC0), and I will do my best to keep this article up to date with relevant changes as the technologies or threat landscape change. I am also writing an expansion the Risk Analysis section to include threat scenarios with Mitre ATT&CK structure and references.

Word count: 9,000+

TL;DR

Aim to maximize user adoption of phishing-resistant auth factors while helping IT reduce password attack vectors, policy maintenance, and support processes.

1. Maximize YubiKeys with user-validating fingerprints (YubiKey Bio) or PINs (YubiKey + PIN) to maximize defenses from phishing threats and to minimize theft attacks. For customers too, not just employees.

2. Remove server-validating second-factors (MFA, 2FA) when using the above auth factors if not limited by rules set by standards bodies. For customers too, not just employees.

3. Support passkeys carefully. Clearly understand the different types of passkeys and their security trade-offs when used in high security environments. For customers too, not just employees.

4. Eliminate weak auth factors and analyze and enhance auth factor reset processes.

5. If the budget allows, gift YubiKeys to employees and their families and offer hands-on user training. When people appreciate the importance of FIDO2, they will naturally adopt YubiKeys in their daily lives, building a culture of security that extends beyond work. If a company plans on taking YubiKeys back after resignations and terminations, they'll be less likely to practice secure authentication in their personal lives.

Scope

Threat modeling for FIDO2/WebAuthn Yubikeys and passkeys for passwordless authentication (secure signle-factor authentication) or in conjunction with multiple factors (multi-factor authentication such as with passwords).

Integration of FIDO2/WebAuthn for Okta IdP from ChromeOS, Linux (w/ Chrome), macOS (w/ Chrome), and Windows (w/ Chrome) workstations. As of writing, Chrome has the best support for FIDO2/WebAuthn, can be centrally managed in an enterprise environment, and works on all workstation types.

Please note, while there are other hardware FIDO2 devices available on the market, this risk analysis dives into the details of YubiKeys. Other devices may not operate in the exact same way, so please be careful not to misunderstand my use of "hardware FIDO2". If I were asked to compare other hardware devices to the YubiKey, I would have to rethink all aspects of this document and potentially rewrite certain sections to be clear about any differences.

Positive Use Cases

1. 100% employee, contractor, and business parter coverage for passwordless authentication via Okta from all platforms (ChromeOS, Linux, MacOS, Windows) and interfaces (browser, application, CLI) using FIDO2/WebAuthn hardware-based (YubiKey) and software-based (passkey) authentication methods.

2. 100% administrator coverage for passwordless authentication via Okta from Chromebooks (a pre-selected Priviledged Access Workstation (PAW)) with YubiKeys for accessing high-risk environments.

3. Zero-trust access control policies using the IdP (Okta Verify, Okta API) with supporting/layered Mobile Device Management (MDM) controls for device posture checks aligned to corporate security policies and standards.

Negative Use Cases

1. A successful phishing attack compromising a user account.

2. Administrative accounts being accessed without the dual security of a PAW and YubiKey.

3. An individual, including employees, using a personal, unmanaged laptop or desktop gaining access to the company network.

4. A device lacking necessary hardware security modules or non-compliant biometrics being able to authenticate without a YubiKey or passkey.

5. Any bypass of the IdP or supporting/layered MDM controls.

Biometric Security Analysis

Biometrics, including fingerprints and faceprints, are often touted for their uniqueness and are considered more convenient and relatively more secure than traditional passwords or passcodes. However, the reality is more nuanced. As highlighted by Ars Technica, attackers have been able to bypass fingerprint authentication with an approximate 80% success rate in tests conducted on devices from major manufacturers like Apple, Microsoft, Samsung, and Huawei. This success rate illustrates that biometric data can indeed be manipulated or mimicked by determined attackers with access to relatively simple technology and a modest budget.

Unlike passwords or PINs, biometric data is immutable. Once compromised, it cannot be changed or revoked. This immutability poses a significant security risk for some, as exemplified by the breach of the Office of Personnel Management (OPM) in which 5.6 million fingerprints of federal employees were copied. The compromise of such irreplaceable identifiers not only exposes individuals to lifelong vulnerabilities but also raises national security concerns, given the potential misuse of this data by adversarial entities.

Kraken Security Labs demonstrated that with just $5 worth of materials, a fingerprint can be lifted off touched objects, creating a synthetic fingerprint capable of bypassing scanners on devices like a MacBook Pro. “[U]nlike a regular password, you leave your fingerprint on taxi doors, iPhone screens, and glasses of wine at your local restaurant.” This security research underscores the vulnerability of biometric systems to relatively low-tech attacks, highlighting the risk of over-reliance on these systems for securing sensitive information and access controls.

The nuanced security architecture of biometric authentication involves a sophisticated interplay between biometric inputs and cryptographic hardware (ie Apple's Secure Enclave). In these systems, biometric data does not directly grant access to the device or platform. Instead, it serves as a key to authenticate the user against the on-device cryptographic module. This module then generates, manages, and/or proves a valid encryption key to macOS or to Okta. This ensures that even if biometric data is compromised, unauthorized access requires stealing the targeted device for either breaking into the device or breaking into Okta. This layered approach to security significantly enhances protection but also underscores the complexity of fully understanding and securing systems against determined attackers.

To deepen the understanding of this nuanced security architecture, it's critical to recognize the distinctions in how biometric systems are integrated, particularly when planning for risk mitigation. For instance, Apple and Microsoft adopt notably different strategies in designing biometric authentication systems for laptops. Microsoft (Windows Hello), constrained by its dependence on a wide array of hardware manufacturers, firmware and driver developers, faces challenges in enforcing stringent requirements, as highlighted by Ars Technica in November 2023. Understanding the details of cryptographic mechanisms is important, particularly when there is an absence of cryptographic mechanisms when transporting biometric authentication data between system components. In contrast, Apple's controlled ecosystem allows for more rigorous standards in its biometric authentication implementation. This disparity underscores the importance of considering the specific architecture and integration approach of biometric systems when assessing security risks and protections.

Lastly, devices are not equally vulnerable. On the other hand, it’s impossible to predict when and where new vulnerabilities will be found, or what arsenal well funded adversaries possess. This security analysis aims to highlight known vulnerabilities in MFA components while being weighed against broad risk for biometric authentication technology.

PINs = Passwordless?

A YubiKey "PIN", as written in this article, includes passcodes and passphrases, given that setting a "PIN" allows for alphanumeric passphrases. YubiKeys are not limited to only 0-9 when setting a PIN.

The concept of "passwordless" authentication, particularly in the context of using a YubiKey coupled with a PIN, represents a significant shift in how we think about securing access to systems and services like Okta. This approach is considered passwordless not because it eliminates all forms of user input that a user must remember, but because it fundamentally changes the nature of secure authentication information being presented to Okta.

To understand why a combination of YubiKey and PIN is classified under passwordless authentication, it's essential to delve into the mechanics of how the YubiKey functions and how the PIN fits into this authentication model. The YubiKey is a hardware device that supports various forms of cryptographic proofs, such as Universal 2nd Factor (U2F), FIDO2, and smart card capabilities. These cryptographic proofs are used to authenticate the user to a service like Okta, without transmitting a traditional password.

The role of the PIN in this setup is to authenticate the user to the YubiKey itself, not to Okta. The PIN is a safeguard that ensures only the authorized user of the YubiKey can activate the YubiKey's cryptographic functions. When the user inserts their YubiKey into a device and is prompted for a PIN, the correct entry of this PIN activates the YubiKey. Subsequently, the YubiKey performs cryptographic operations that prove the user's identity to Okta or another service. This process involves the YubiKey creating a digital signature or other cryptographic response that only it can generate, thanks to its secure, embedded cryptographic keys.

It's important to emphasize that Okta, in this scenario, does not receive or process the PIN. Instead, Okta interacts with the cryptographic proof provided by the YubiKey. This is a critical distinction that makes the system "passwordless." Okta verifies the authenticity of the cryptographic proof against the registered details of the YubiKey, thus authenticating the user. This method is inherently more secure than traditional passwords, which can be intercepted, stolen, or guessed. FIDO2 cryptographic proofs, on the other hand, are unique to each authentication session, time dependent, and cannot be reused by an attacker.

Lastly, this approach aligns with the principles of multi-factor authentication (MFA), requiring something the user has (the YubiKey) and something the user knows (the PIN). However, unlike traditional MFA that might use a password as one of the factors, this method relies on cryptographic authentication, which is significantly more resilient against phishing, man-in-the-middle attacks, and other common security threats. In essence, considering YubiKey plus PIN as passwordless stems from the fact that the authentication process with Okta and similar platforms does not involve a shared secret like a password being sent over the network. Instead, it leverages the robust security of hardware-based cryptography to verify identity locally. This shift not only enhances security but also simplifies the user experience, as users no longer need to remember complex passwords or change them regularly.

Software passkeys vs hardware YubiKeys

Passkeys, credentials used in FIDO2 authentication, can be supported by software-based systems or secured by hardware authenticators like YubiKeys. While both approaches implement strong, phishing-resistant authentication standards, they differ in how securely credentials are protected and verified.

Software-based passkeys offer user-friendly, seamless biometric or PIN-based authentication without requiring additional devices. While convenient, these passkeys rely on the security posture of the underlying system and can be vulnerable to sophisticated malware if the device is compromised. Additionally, cloud-synced passkeys depend on the security of cloud infrastructure and the personal settings of user's accounts.

Hardware-based YubiKeys securely store private keys within a tamper-resistant physical token that isolates cryptographic operations from potentially compromised host systems. This makes hardware tokens more resilient against remote attacks and phishing, as the private key never leaves the device. User interaction, such as a touch to confirm or, in the case of the YubiKey Bio, PIN entry or a fingerprint swipe, adds an extra layer of verification.

Both software and hardware methods use public key cryptography, providing robust security properties, but each comes with unique trade-offs which this articles aims to help document.

Types of Passkeys

Generally speaking there are two types of passkeys that each carries unique risks. I'm also breaking down each of these two types into two sub-types for further security engineering clarity. Each type and sub-type has categorical risks. Additionally, operating system or web browser implementation can significantly change the nature of risks associated with using any one type of passkey.

Synced Passkeys

Cloud-synced Passkey

• User Presence
• Phishing Resistant
• User Verifying

Not:

• Device Bound
• Hardware Protected

There is no guarantee that a synced passkey without “passkey attestation” cannot be used somewhere else. That is an intentional, user-focused portability feature that was not intended for enterprise use.

Using Apple as an example, use of passkeys on Apple devices automatically sync to a user's iCloud account via what is now called Apple Passwords. If a threat actor is able to compromise a targeted user's iCloud account and is able to add an Apple device owned by the malicious user as an authenticated device, the malicious user would have access to the targeted user's passkeys. This is by design for passkey portability and ease-of-use.

Cloud-synced Passkey w/ Attestation

• User Presence
• Phishing Resistant
• Device Bound
• User Verifying

Not:

• Hardware Protected

The addition of Passkey Attestation is supposed to make a passkey device-bound even if it syncs to the cloud.

Apple, for example, allows enterprises utilizing MDM to enable Apple Passkey Attestation.

Device Bound Passkeys

Local passkeys

Auth Method Characteristics:

• User Presence
• Phishing Resistant
• Device Bound
• User Verifying

Not:

• Hardware Protected

For the common enterprise operating systems used today – iOS, macOS, Windows, ChromeOS – local passkeys are created by and authenticated by a private key made and stored in a hardware security module such as the laptop's TPM or Apple's Secure Enclave.

Since the passkey exists on-disk as software, usually in an encrypted state, managed by the OS or by a web browser, the passkey will not work on any other device because of the requirement of the local hardware security module that generated the passkey.

In other words, the private key in the hardware security module that generates the private key for a passkey is hardware protected. But the passkey private key is not.

However, if the outer layer of encryption can be defeated, and the private key material of the passkey can be exported, it is no longer protected by, nor requires, the local hardware security module to be used.

Using a local passkey means:

1. The hardware security module is present

2. The passkey private key is present and managed by the private key in the hardware security module

3. The passkey is validated by something user-verifying, typically a PIN or biometric, which the user has to input, which is also validated by the local hardware security module's private key

4. The timing of the use of the passkey and the user verification has to be accurate. WebAuthn requires time intervals of each step has not timed out, and that time measurement is cryptographically secure.

Local passkey w/ attestation

• User Presence
• Phishing Resistant
• Device Bound
• User Verifying

Not:

• Hardware Protected

Passkey Attestation is an additional cryptographic proof that ties a passkey to a specific hardware security module. If the private key material of a passkey with attestation is exported, no other hardware security module can authenticate its use.

The addition of passkey attestation greatly improves the security of a local passkey due to layered security, but it is most important when the passkey can or will be synced to the cloud and kept on numerous devices.

FIDO2 1FA: better than classic 2FA/MFA?

The below table and terms are adapted from Okta's multifactor authentication documentation.

User presence:

These authenticators require human interaction.

Phishing-resistant:

These authenticators don't provide any authentication data that a user can share with others. Users therefore can't be tricked into sharing their credentials in phishing campaigns. See Phishing-resistant authentication and Okta solutions for phishing resistance.

Device-bound:

These authenticators are associated with a specific device.

Hardware-protected:

These authenticators require a physical device to authenticate.

User verifying:

These authenticators prove that a specific user is the one who is authenticating.

These five "authentication method characteristics", defined by Okta, each mitigates entire classes of attacks. If I had to write an SSO security standard for a company, I would use this table for categorical clarification about which methods are permitted. I would require User Presence, Phishing Resistance, Device Bound, and User Verifying authentication characteristics. Hardware Protected is ideal, but would rule out passkeys. My personal preferences would rule out PIN-less YubiKeys and passkeys that sync to the cloud without proven passkey attestation controls.

The Device Bound characteristic is messy when looking at passkeys. In short, without robust MDM and/or cloud security controls, social engineering threats that target less secure cloud accounts where passkeys sync is a real threat. Like Apple iCloud.

The Hardware Protected characteristic is also messy. It's commonly presumed that Apple-generated passkeys are stored in Apple device's Secure Enclave, for example, which is not true. Apple-generated passkeys use Secure Enclave to generate and validate passkeys, but these passkeys are stored in the iCloud Keychain -- in software. Similarly, Chrome-generated passkeys, while they will use a system's TPM or Secure Enclave, are stored in a Google-managed encrypted database -- in software.

While there are always edge cases, a single, modern, properly managed (User Verifying) FIDO2 authenticator such as a YubiKey or credential like a passkey does not require a server-validated second-factor for authentication because the first auth factor is robust: it will adequately mitigate most risks in most situations. FIDO2/WebAuthn, when configured correctly, offers client-validated two-factor authentication, which becomes clear in the following section. Classic, password-based MFA is an approach to authenticate where two or more auth factors have significant weaknesses, so as a matter of layered security, multiple auth types are necessary to secure access to a remote system.

YubiKeys are hardware devices that cannot be easily copied -- but beware older keys -- and passkeys are software cryptographic keys that are not easily exportable to arbitrary people. Both maintain strong risk mitigations of their own, however passkey implementations vary widely. Passwordless auth factors are not immune from phishing attacks. It is possible for social engineers to pretend to be the helpdesk of the company of the targeted employee and in effect steal a YubiKey along with an associated PIN. Passkeys, on the other hand, are exportable in many situations and therefore may be transferable. Without passkey attestation or certain controls to make passkeys device-bound, it's possible for social engineers to copy, steal, or hijack cloud accounts with synced private keys. More on these risks later.

Risk Analysis

The following risk analysis is scoped to common workstation types and common authentication types. There are more of each; for example, I did not dive into mobile phones or tablets. I also did not work with third-party password managers that can manage passkeys. This analysis aims to provide a basic template for adding more device types or authentication types.

This risk analysis is also focused on Okta's capabilities as of early 2024. It may be possible now or in the future that Okta allows additional server-validated 2FA auth factor combinations, including an ideal possibility of allowing the first server-validated auth factor to be a passkey instead of a password with a second server-validated auth factor be a YubiKey. In my testing, I was not able to configure Okta to allow a passkey + YubiKey combination, for example. I hope that server-side authentication systems develop to the point of offering support for multiple forms of FIDO2 auth factors.

Authentication and Workstation Types Matrix

Below you will see several tables with specific color-coding to differentiate aspects of these authentication methods and the workstations from which they can be used. These tables offer quick-glance, high-level risk indicators. The low-level risk analysis for each authentication type follows this section.

• Green: Advised
• Yellow: Not Advised
• Red: Dangerous

As you will see below, two-factor authentication (2FA) requires two of: something you have, something you know, or something you are. It becomes clear why a single FIDO2/WebAuthn method is 2FA when there is user-validating cryptographic authentication baked into the protocol, when configured correctly. This nuanced distinction, when juxtaposed to classic 2FA/MFA, is that the validation of the user is occurring locally instead of by the server/IdP -- the former being more secure in some meaningful contexts, but not all.

"Server-validated" (2FA) can mean:

1. an IdP, like Okta
2. IdP-less situations
   2a. super admins or break-glass accounts
   2b. online services without SSO integration capabilities

"Client-validated" (2FA) can mean:

1. a workstation, like with Apple's macOS Touch ID, providing local cryptographic validation of a passkey
2. a fully-integrated hardware token, like a YubiKey, including a web browser or CLI terminal that performs PIN validation

High-Level Risk Analysis for Passwordless, server-validated 1FA, client-validated 2FA

These five authentication types are usable options if the company decides to adopt single-factor, passwordless authentication for Okta SSO.

The first two types are hardware based, and last three (in light blue) utilize software-based storage of passkeys with hardware-backed (TPM, Secure Enclave) creation and validation. As you can see, the passkey methods are system specific. Windows Hello (option 5) caries notable risk compared to the alternative passwordless options, which this article will dive into in the next section.

To my knowledge, there is no known, production-ready, centrally-managed passkey option for Linux workstations. Theoretically, Chrome (browser) will generate passkeys with a workstation's TPM, validated by a fingerprint reader, and Chrome will store and sync a passkey with Google Password Manager. This may have the ability to be "centrally managed" to a degree if a company is using Google Workspace for company email and MDM. It will not affect or help passkeys needed for CLI work. Additionally, third-party password managers that have built in passkey management options could be used, but that is true for any operating system, and password-manager-managed passkeys have distinct security tradeoffs. I have not tested either of these scenarios. YubiKeys are ideal when supporting Linux workstations in addition to offering the most robust security.

High-Level Risk Analysis for Server-validated 2FA

Auth methods 6 through 15 include options that are not FIDO2. Further, Push, TOTP, YubiKey (PIN-less), SMS, and "Security" Questions are here to show juxtaposition. These auth methods are common in enterprise environments. Your company may have others, and they should be documented in a similar way.

High-Level Risk Analysis for Passwordless, server-validated 1FA, client-validated 1FA

Last but not least, auth method 16 is simply a YubiKey without a second-factor of any kind, server-validated or client-validated. It should be clear that there is no native or supplemental second-factor that meets the "something you have, know, or are" criteria. Those facts aside, a PIN-less YubiKey, by itself, is still strong when it comes to phishing resistance. Low-level analysis below.

Risk Discussion

My methodology for defining a high-level “risk” for each of the risk categories is “averaged” based on overall mitigated risk factors when using the above authentication methods, either single-factor or multi-factor.

Advising

My “advised” recommendations stem from one simple criteria: No High or Critical risks.

Any amount of Medium risks can often be minimized with layered security controls. However, pay attention to my notes. Some Medium risks should be elevated to High risks if a company or user's threat model includes moderate to high likelihood of targeted attacks. In these situations, my advisement shifts to Not Advised, and it is up to the company to accept certain medium to high risks.

Risks Definitions

• Spoofing Risk: The likelihood that an attacker could replicate or spoof the authentication method.

• Theft/Loss Risk: The risk of the authentication method being lost, stolen, or guessed.

• Phishing Risk: The susceptibility of the authentication method to phishing attacks.

• Technical Vulnerabilities: The risk of publicly known technical flaws or vulnerabilities anywhere in the authentication method compute stack.

Low-Level Risk Analysis for Passwordless, server-validated 1FA, client-validated 2FA

1. YubiKey + PIN (Advised)

1a. Combined Auth Method Characteristics

• User Presence
• Phishing Resistant
• Device Bound
• User Verifying
• Hardware Protected

1b. Targeted Theft Risk, Medium

YubiKeys are easy to lose, easier to have stolen, and impossible to track since they operate without connectivity. There are at least three increased risks with regard to a stolen YubiKey that has a PIN configured:

• Guessing: It should be assumed that most people will choose a PIN that they will not easily forget. Therefore, it is common for employees to choose PINs that they use in their personal lives. For example, for their ATM debit card. A determined threat actor may have access to privileged data or hacked datasets that would allow the attacker to presume a targeted user's PIN with high probability.

• Copying: Technical vulnerabilities, known or future, may allow an attacker to copy the YubiKey, and possibly return the stolen YubiKey to its owner without the owner knowing it went missing. Having a duplicated YubiKey may be combined with other risks.

• Social engineering: A determined threat actor may be able to phish or social engineer an employee into disclosing their PIN, even if the YubiKey has already been taken from their possession.

1c. Note

YubiKeys have built-in defense mechanisms protecting against repeated PIN guessing, and so does Okta. Further, companies could purchase the FIPS-certified YubiKeys that require a user set a 6-digit PIN instead of a default 4-digit PIN, or they could educate employees about the risks and ask them to use a unique PIN.

1d. Note

With this method of client-validated 2FA, as discussed earlier, the PIN certifies the user to the security key. Neither the YubiKey nor the PIN can be used independently of each other for any authentication factor. Therefore the use of a PIN is not the same as using a password as an individual factor for authentication into a remote system.

2. YubiKey Bio (Advised)

2a. Combined Auth Method Characteristics

• User Presence
• Phishing Resistant
• Device Bound
• User Verifying
• Hardware Protected

2b. Spoofing Risk and Targeted Theft Risk, Medium

It is a fact that bioreaders are susceptible to artificially constructed fingers and faces. Such authentication methods are immutable. Given a determined attacker's ability to easily steal a YubiKey Bio, the attacker would be in possession of half of the authentication system.

With no other authentication factor to mitigate the risk of a stolen YubiKey Bio being misused, this overall risk is Medium when considering low-skilled attackers due to the fact that YubiKeys have a native anti-brute-forcing feature.

However, if a specific user's threat model includes determined or well-funded threat actors, this Spoofing risk should be increased to High and automatically the overall recommendation would be changed to Not Advised.

2c. Note

To activate a YubiKey Bio, a user first must add a PIN, just like if a user had a YubiKey non-Bio and was enabling a PIN. The PIN is used as a backup method of authentication after a small number of fingerprint swipe attemps.

YubiKey Bio devices ensure a limited amount of failed authentication attempts overall. A YubiKey will cease functioning after a certain amount of retries. This security control is in addition to Okta’s limit of failed authentication attempts.

2d. Note

YubiKey Bios, while more expensive, are ideal for most end-users. Users do need to set (and remember) a PIN, but the PIN does not need to be used in most situations. The ease-of-use will increase adoption while also lowering PIN- (YubiKey-) resets.

It's recommended that companies teach users of YubiKeys Bios to set unique PINs and to store those PINs in their company-approved password managers.

3. macOS Touch ID (Advised)

3a. Combined Auth Method Characteristics

• User Presence
• Phishing Resistant
• User Verifying

Not:

• Device Bound
• Hardware Protected

3b. Spoofing Risk, Medium

Bioreaders are susceptible to artificially constructed fingers or faces. The risk is increased to Medium since a threat actor is likely in possession of the first client-validated auth factor (Secure Enclave) when a laptop is also lost or stolen.

Since Macbooks are usually left turned-on, an since macOS Touch ID is also used to gain access to the system, when lost or stolen, any compromise of Touch ID would not only allow access to the system but also to Okta. However, Macbooks will revert back to requiring the user's password to enter the system if enough time as passed.

Like YubiKey Bio risks, if a specific user's threat model includes determined or well-funded threat actors, this Spoofing risk rating should be increased to High and automatically the overall risk rating should be changed to Not Advised.

3c. Targeted Theft Risk, Medium

Since one’s fingerprint is validating the user to Secure Enclave, and since both Secure Enclave and the bioreader is lost when a Macbook is lost or stolen, it carries similar risks when a YubiKey Bio is lost or stolen. Please read that section as it is highly similar.

3d. Phishing Risk, Medium

While the auth method characteristic Phishing Resistant is true, in a broader sense, due to the nature of cloud-synced passkeys, there is meaningful, extrinsic phishing risk that a company should consider. Due to how Apple employs passkeys, requiring a reliance on iCloud Keychain, Apple passkeys are not Device Bound. If an attacker is able to social engineer a user to gain access to a user's Apple account, the attacker may be able to gain access to passkey private key material. If a user is signed into their personal Apple account, companies will have little to no control or visibility into personal accounts.

I go into greater detail looking at Apple iCloud Keychain risks later in this article (WIP).

3d. Note

This method of authentication employs software FIDO2: passkeys. It is not a 1:1 replacement for a YubiKey. Secure Enclave generates a private key and stores the private key in iCloud Keychain, in software, because, in order to use passkeys on Apple systems, iCloud and iCloud Keychain must be enabled. However there still are strong security guarantees. It is not trivial to export a passkey arbitrarily, and it is not easily phishable. Secure Enclave + the user's unique fingerprint are both required to activate the passkey.

3e. Note

Exported passkey private keys from Apple Passwords (formerly iCloud Keychain) can be used by malicious attackers if successfully copied or stolen if a company is not using MDM that also enables passkey attestation.

3f. Note

Neither Secure Enclave nor one’s fingerprint can be used independently. Secure Enclave is designed to securely store cryptographic keys and perform cryptographic operations, while Touch ID is used to authorize the use of these keys.

3g. Note

Like YubiKey Bio devices and YubiKey + PIN, macOS Touch ID ensures a limited amount of failed authentication attempts. Touch ID will cease functioning after a certain amount of retries. This security control is in addition to Okta’s limit of failed authentication attempts.

4. Chromebook TPM + fingerprint (Advised)

4a. Combined Auth Method Characteristics

• User Presence
• Phishing Resistant
• User Verifying

Not:

• Device Bound
• Hardware Protected

4b. Spoofing Risk, Medium

Bioreaders are susceptible to artificially constructed fingers or faces. The risk is increased to Medium since a threat actor is likely in possession of the first client-validated auth factor (TPM) when a laptop is also lost or stolen.

Like YubiKey Bio risks, if a specific user's threat model includes determined or well-funded threat actors, this Spoofing risk rating should be increased to High and automatically the overall risk rating should be changed to Not Advised.

4b. Targeted Theft Risk, Medium

Since one’s fingerprint is validating the user to TPM, and since both TPM and the bioreader is lost when a Chromebook is lost or stolen, it carries similar risks when a YubiKey Bio is lost or stolen. Please read that section as it is highly similar.

4c. Phishing Risk, Medium

While the auth method characteristic Phishing Resistant is true, in a broader sense, due to the nature of cloud-synced passkeys, there is meaningful phishing risk that a company should consider. Ever since Google changed how passkeys are managed in Chrome, passkeys are no longer Device Bound. If an attacker is able to social engineer a user to gain access to a user's Google account, the attacker may be able to gain access to passkey private key material. If a user is signed into their personal Google account, companies will have little to no control or visibility into personal accounts.

4d. Note

If used as a PAW, I would strongly advise Okta admins to employ a ChromeOS-specific policy to require server-validated 2FA and not solely relay on ChromeOS's fingerprint security. Or, to simply require the use of a YubiKey + PIN. Even a YubiKey Bio, i believe, would be a more trustworthy client-validated 2FA method to avoid the risks of random OEM manufacturing. Employing YubiKeys with Chromebooks as PAWs is ideal because it's likely that an admin uses a Windows laptop or Macbook as their main workstation.

4e. Note

I'm not aware of any specific, known exploits of Chromebook bioreader attacks. Unlike Macbooks, and more like Windows laptops, Chromebooks are manufacturered by many different OEMs. While a TPM + fingerprint combination sounds similiar to a Macbook, I would not give it the same level of trust. I think of it as somewhere in between a Macbook and a Windows laptop in terms of physical security risk.

If know

5. Windows Hello (Not Advised)

5a. Combined Auth Method Characteristics

• User Presence
• Phishing Resistant
• User Verifying

Not:

• Device Bound
• Hardware Protected

5b. Spoofing Risk, High

Bioreaders are susceptible to artificially constructed fingers/faces, especially on Windows laptops. The risk of Windows Hello spoofing is high due to Microsoft’s and OEM’s track record of inferior technology compared to Apple. The risk here is elevated due to a lack of a second auth factor which raises the overall spoofing risk.

5c. Accidental Loss and Theft for Resale, Medium

Laptops are not easily lost of stolen unless the owner travels a lot for work. However due to the ease in which a laptop can be misplaced or stolen, this is not an insignificant risk, especially coupled with the scenario where there is no second-factor for authentication. If the laptop owner travels for work, this risk score would raise to High.

5d. Targeted Theft Risk, High

Laptops do not require a great deal of effort or cost to steal for a determined threat actor. Combined with the Critical Risks associated with default BitLocker configurations and with Windows Hello, and the overall risk (platform insecurity) with Windows laptops in general (see below), this has an increased risk.

5e. Phishing Risk, Medium

As of October 2024, Microsoft has announced that passkeys on Windows systems will become trivial to sync to either a user's signed-in Microsoft account or to a third party service like BitWarden or 1Password.

While the auth method characteristic of Phishing Resistant is true, in a broader sense, due to the nature of cloud-synced passkeys, there is meaningful, extrinsic phishing risk that a company should consider. Via default Windows Hello workflows, users are asked to sync their passkeys to the cloud. While this is opt-in, most users are likely to enable this convenience feature. If an attacker is able to social engineer a user to gain access to a user's cloud account, the attacker may be able to gain access to passkey private key material. If a user signs into their personal cloud account, companies will have little to no control or visibility into personal accounts.

5f. Technical Vulnerabilities, Critical

There are active, cheap exploits against Windows BitLocker. Given:

• How easy it is to steal a laptop
• A default BitLocker configuration is known-vulnerable to a myriad of physical-access attacks

The only potential method to reduce risk to gain access to a shut down (turned off) Windows workstation is for the company to enable a BIOS password on all Windows laptops and enable BitLocker hardening through Group Policy on all Windows laptops. Specifically, forcing users to set a pre-boot PIN. However, having a pre-boot PIN enabled may not help in some scenarios where a Windows laptop is stollen in a turned-on, suspended, or hibernation state.

Given the IT department impact, and the user impact of requiring pre-boot PINs to boot into Windows, it is not common for companies to add these technical inconveniences. For example, Windows patching is made significantly harder when there is a pre-boot PIN for IT and for the end-user.

There are active, cheap exploits against Windows Hello.

In short, a threat actor is able to enroll a fingerprint into a company-owned laptop fingerprint sensor and use that arbitrary fingerprint to authenticate via Windows Hello. This attack would allow a threat actor to log into Windows and authenticate into Okta. Based on the public information about these exploits, they do not appear to be patchable. Most companies do not have any firmware patching or firmware hardening controls in place, potentially allowing an attacker to boot into Linux on a stolen Windows laptop in order to perform this arbitrary-fingerprint-enrollment attack.

The linked Ars Technica article discussing this attack, and the public, associated research, calls our many popular laptop OEMs. Given the scale of vulnerable systems, I would operate on the assumption that all Windows laptop OEMs are vulnerable until proven otherwise.

5g. Note

Unlike the server-validated 2FA Password + Windows Hello, due to the known exploits against Windows Hello, this is not an acceptable risk for a company to use. Not only is it likely that an attacker could use a related exploit to gain access into the system from a shutdown state, they then would be able to easily gain access into Okta from the same system, and likely do so without triggering any system health checks.

Low-Level Risk Analysis for Server-validated 2FA

6. Password + YubiKey + PIN (Advised)

6a. Combined Auth Method Characteristics

• User Presence
• Phishing Resistant
• Device Bound
• User Verifying
• Hardware Protected

6b. Targeted Theft Risk, Medium

YubiKeys are easily lost or stolen. However, the use of a PIN to authenticate the user to the YubiKey significantly mitigates this risk.

6c. Note

One issue that may arise with this method is that users may reuse a passcode that they use somewhere else in their life, like an ATM card passcode. It’s advised that users use 6 digit passcodes (or more) instead of 4. The FIPS-series of YubiKeys require 6 digits minimally.

6d. Note

This combined MFA method has strong security properties: something you know, something you have, and something else that you know.

6e. Note

Like YubiKey Bio devices, YubiKey + PIN ensures a limited amount of failed authentication attempts. A YubiKey will cease functioning after a certain amount of retries. This security control is in addition to Okta’s limit of failed authentication attempts.

7. Password + YubiKey Bio (Advised)

7a. Combined Auth Method Characteristics

• User Presence
• Phishing Resistant
• Device Bound
• User Verifying
• Hardware Protected

7b. Spoofing Risk, Medium

Bioreaders are susceptible to artificially constructed fingers/faces. The risk of Windows Hello spoofing is high due to Microsoft’s and OEM’s track record of inferior technology compared to Apple. However, the risk is lowered due to the moderate second factor provided by a password.

7c. Targeted Theft Risk, Medium

YubiKeys are easily lost or stolen. However, the use of a bioprint to authenticate the user to the YubiKey significantly mitigates this risk.

7d. Note

Bioprint validation of a YubiKey mitigates a great deal of risk associated with loss/theft risks of a YubiKey, and when combined with a password, this has strong security properties: something you know, something you have, and something you are.

8. Password + macOS Secure Enclave + Touch ID (Advised)

8a. Combined Auth Method Characteristics

• User Presence
• Phishing Resistant
• User Verifying

Not:

• Device Bound
• Hardware Protected

8b. Spoofing Risk, Medium

Touch ID, like any bioreader, is susceptible to artificially constructed fingers/faces. Like YubiKey Bio devices and YubiKey + PIN, Touch ID ensures a limited amount of failed authentication attempts. Touch ID will cease functioning after a certain amount of retries. This security control is in addition to Okta’s limit of failed authentication attempts.

8c. Targeted Theft Risk, Medium

Laptops are fairly trivial to steal. When stealing a Macbook, the Secure Enclave + bioreader that allows Touch ID to function is lost too. During a targeted attack, Touch ID compromise risk would be considered a High Risk if it were not for the mitigating factor of MFA.

8d. Phishing Risk, Medium

While the auth method characteristic Phishing Resistant is true, in a broader sense, due to the nature of cloud-synced passkeys, there is meaningful, extrinsic phishing risk that a company should consider. Due to how Apple employs passkeys, requiring a reliance on Apple Passwords (formerly iCloud Keychain), Apple passkeys are not Device Bound. If an attacker is able to social engineer a user to gain access to a user's Apple account, the attacker may be able to gain access to passkey private key material. If a user is signed into their personal Apple account, companies will have little to no control or visibility into personal accounts.

I go into greater detail looking at Apple iCloud Keychain risks later in this article (WIP).

8e. Note

Even though there are two Medium risks identified, the combination of a Password + Touch ID adequately mitigates the Medium risks. While passwords alone are vulnerable to phishing attacks, the second factor mitigates the overall risk considerably. Touch ID consists of two strong factors due to Apple’s strong, integrated design: Secure Enclave is something you have, and Touch ID (the biometric reader component) attests something you are. There are no known vulnerabilities between Secure Enclave and the fingerprint reader, unlike TPM + Windows Hello.

9. Password + Chromebook TPM + fingerprint (Advised)

9a. Combined Auth Method Characteristics

• User Presence
• Phishing Resistant
• User Verifying

Not:

• Device Bound
• Hardware Protected

9b. Spoofing Risk, Medium

Bioreaders are susceptible to artificially constructed fingers or faces. The risk is increased to Medium since a threat actor is likely in possession of the first client-validated auth factor (TPM) when a laptop is also lost or stolen.

Like YubiKey Bio risks, if a specific user's threat model includes determined or well-funded threat actors, this Spoofing risk rating should be increased to High and automatically the overall risk rating should be changed to Not Advised.

9c. Targeted Theft Risk, Medium

Since one’s fingerprint is validating the user to TPM, and since both TPM and the bioreader is lost when a Chromebook is lost or stolen, it carries similar risks when a YubiKey Bio is lost or stolen.

9d. Phishing Risk, Medium

While the auth method characteristic Phishing Resistant is true, in a broader sense, due to the nature of cloud-synced passkeys, there is meaningful phishing risk that a company should consider. Ever since Google changed how passkeys are managed in Chrome, passkeys are no longer Device Bound. If an attacker is able to social engineer a user to gain access to a user's Google account, the attacker may be able to gain access to passkey private key material. If a user is signed into their personal Google account, companies will have little to no control or visibility into personal accounts.

9e. Note

Adding a second server-validated auth factor does reduce risk. However, due to the nature of passwords, the risk is not significantly reduced. It's important to call out the increased risks even if they are marginal in a server-validated 2FA situation.

10. Password + Push (Not Advised)

10a. Combined Auth Method Characteristics

• User Presence

Not:

• Phishing Resistant
• Device Bound
• User Verifying
• Hardware Protected

10b. Targeted Theft Risk, Medium

Personal cell phones are fairly trivial to steal. During a targeted attack, passcode (public shoulder surfing, etc) compromise risk would be considered a High Risk if it were not for the mitigating factor of MFA.

10c. Phishing Risk, High

Since users might receive frequent push notifications, they could inadvertently approve a fraudulent request, especially if the attacker times it with a legitimate login attempt. Further, push-based authentication is particularly vulnerable to what's known as an 'exhaustion attack'. Threat actors may repeatedly send fraudulent push authentication requests to the user's device. Over time, the user, overwhelmed or desensitized by the constant stream of requests, may inadvertently approve a malicious request.

10d. Note

Both methods here individually carry high risks for phishing, so one method does not significantly mitigate the risks with the other.

11. Password + TOTP (Not Advised)

11a. Combined Auth Method Characteristics

• User Verifying

Not:

• User Presence
• Phishing Resistant
• Device Bound
• Hardware Protected

11b. Targeted Theft Risk, Medium

Personal cell phones are fairly trivial to steal. During a targeted attack, passcode (public shoulder surfing, etc) compromise risk would be considered a High Risk if it were not for the mitigating factor of MFA. Further, Google account takeover during targeted attack carries risk given Google Authenticator’s recent change to sync TOTP private tokens to Google Cloud for ease of use.

11c. Phishing Risk, High

Threat actors can create fake login pages that prompt users to enter their TOTP . Once the user inputs the TOTP into the phishing site, the attacker can quickly use it to gain unauthorized access to the user's account, as these passwords are typically valid for a short period (usually 30 seconds to a minute). This type of attack requires speed but is entirely feasible, given the automated nature of many phishing tools. Further, TOTP passcodes in apps like Google Authenticator are more susceptible than passwords when it comes to spear phishing.

11d. Note

Both methods here individually carry high risks for phishing, so one method does not significantly mitigate the risks with the other.

12. Password + YubiKey (Advised)

12a. Combined Auth Method Characteristics

• User Presence
• Phishing Resistant
• Device Bound
• Hardware Protected
• User Verifying

The User Verifying characteristic is added back because of the use of a password.

12b. Targeted Theft Risk, Medium

YubiKeys are fairly trivial to steal. A YubiKey with no PIN to validate the user is a High risk. The overall risk is reduced since of the layered security of a password. Strictly speaking, it meets all of the Auth Method Characteristics defined earlier.

12c. Phishing Risk, Medium

Passwords are generally susceptible to phishing and other attacks. The reason why Phishing risk is not High is because of the layered security of the YubiKey.

12d. Note

The combination of Password + YubiKey does not adequately mitigate overall risk for a determined attacker. Password reuse is highly likely, in part because of commonly forced password changes at a company, and due to the fact that individual’s passwords are harvested via database hacks almost everywhere on the internet. The two factors are both weak, even when combined, if a company or user's threat model includes medium to high risk of targeted attack.

13. Password + Windows Hello (Not Advised)

13a. Combined Auth Method Characteristics

• User Presence
• Phishing Resistant
• User Verifying

Not:

• Device Bound
• Hardware Protected

13b. Spoofing Risk, Medium

Bioreaders are susceptible to artificially constructed fingers/faces, especially on Windows laptops. The risk of Windows Hello spoofing is high due to Microsoft’s and OEM’s track record of inferior technology compared to Apple, but the moderate security provided by the second factor of a password lowers the overall spoofing risk.

13c. Targeted Theft Risk, Medium

Laptops do not require a great deal of effort to steal for a determined threat actor. Combined with the Critical Risk associated with Windows Hello, and the overall risk (platform insecurity) with Windows laptops in general, this has an increased risk.

13d. Technical Vulnerabilities, Critical

There are active, cheap, unpatched exploits against Windows Hello; specifically, on WebAuthn-compliant Dell laptops. In short, a threat actor is able to enroll a fingerprint into the company-owned Dell fingerprint sensor and use that arbitrary fingerprint to authenticate via Windows Hello. This attack would allow a threat actor to log into Windows without a password (if configured) and authenticate into Okta if the threat actor also had the user’s password. Based on the public information about these exploits, they do not appear to be patchable. company does not have adequate firmware patching controls in place, potentially allowing an attacker to boot into Linux on a stolen Windows laptop in order to perform this specific arbitrary-fingerprint-enrollment attack.

13e. Note

Windows Hello has a long history of insecurity. Due to the fact that Microsoft has to develop OS/kernel support for third-party hardware, third-party firmware, and third-party drivers (which are notoriously bad) for the underpinning of Windows Hello to work on millions of laptop SKUs, Windows Hello will likely never be as secure compared to a fully integrated, locked down Apple Macbook.

14. Password + SMS (Dangerous)

14a. Combined Auth Method Characteristics

• User Verifying

Not:

• User Presence
• Phishing Resistant
• Device Bound
• Hardware Protected

14b. Spoofing Risk, High

The risk associated with SIM card spoofing (aka duplicating or cloning, with the help of a social engineered or coerced telecommunications company) is significant, particularly when facing a determined adversary. This attack allows unauthorized access to copies of an individual's SMS messages, including those containing one-time passcodes.

14c. Targeted Theft Risk, High

The risk associated with SIM card hijacking is significant, particularly when facing a determined adversary. This attack allows unauthorized access to an individual's SMS messages, including those containing one-time passcodes.

14d. Phishing Risk, High

SMS-based passcodes, although typically time-sensitive, are highly susceptible to phishing attacks. It's common for attackers to impersonate corporate IT or security personnel, using intimidation tactics to extract these passcodes from unwary employees.

14e. Technical Vulnerabilities, Critical

The underlying technology of telecommunication networks, particularly SS7 (Signaling System No. 7), presents a critical vulnerability for SMS passcodes. This legacy technology means SMS messages are essentially unencrypted during transmission, allowing determined attackers to intercept or even reroute these messages. This inherent vulnerability in SS7 is fundamental and unlikely to be rectified in the future.

15. Password + Questions (Dangerous)

15a. Combined Auth Method Characteristics

• User Verifying

Not:

• User Presence
• Phishing Resistant
• Device Bound
• Hardware Protected

15b. Targeted Theft Risk, Critical

The often easily discoverable nature of answers to “security questions” cannot be understated. These questions are often easily obtainable by a determined social engineer. Personal information used as answers may be accessible through social media or other public records. Further, the sheer amount of hacked information from other companies makes information disclosure a pervasive and escalating concern. The frequent occurrence of data breaches means that personal information often used in security questions may already be exposed and accessible to threat actors of all kinds.

If a user is targeted for obtaining answers to basic questions, it is equally trivial to target them for passwords. The overall risk here is not reduced for targeted attacks in part because both vulnerabilities are remotely exploitable.

15c. Phishing Risk, High

“Security questions” are highly vulnerable to phishing attacks, even more so than passwords. Attackers can trick users into revealing their answers through deceptive emails, social media messages, or fake security prompts. This is an even higher risk if the server-validated challenges are static questions. The overall risk is reduced to High because of the layered security offered by the server-validated 2FA password.

Low-Level Risk Analysis for Passwordless, server-validated 1FA, client-validated 1FA

16. YubiKey (Not Advised)

16a. Combined Auth Method Characteristics

• User Presence
• Phishing Resistant
• Device Bound
• Hardware Protected

Not:

• User Verifying

16b. Targeted Theft Risk, Critical

A YubiKey with no PIN to validate the user is a significant risk, even if it is not remotely exploitable.

A significant risk of using a YubiKey only, with no PIN and no other auth factor, is from coworkers or even family members. People close to the employee likely knows exactly how to use a stolen YubiKey, knows who it's for, and likely understands what access it grants them. The only way to lessen the risk is to layer on Okta or MDM managed system health checks so that a YubiKey cannot be used from a system that does not belong to the company. If a device is not managed properly and does not quickly enable a system lock screen due to inactivity, using a stolen YubiKey from the targeted user's own computer is a significant risk and would cause inaccurate audit logs, further protecting the attacker.

Then there is also coworker sharing. This is different from a coworker stealing a fellow employee's YubiKey. This is intentional sharing of access. Further, if a coworker has temporary access to a peer's Okta account, they would be able to add their own YubiKey, allowing them to have permanent, long-term access to their coworker's SSO.

16c. Note

Accidental Loss is a Low risk because someone who finds an arbitrary YubiKey is not likely to know who it belongs to or what accounts it is used for. This information is not discoverable from posession of a YubiKey.

Theft for Resale is Low because YubiKeys are not particularly valuable to the general public.

When an employee notices that they are missing their YubiKey, they must report it to the company, and IT must simply unenroll the YubiKey from Okta to mitigate all risk.

Adoption Challenges

Weak Defaults

First and foremost, SSO accounts cannot have weak fallback authentication options. A company can't allow users (or attackers) to downgrade authentication with the IdP by way of supporting weak (phishing-vulnerable) reset mechanisms such as TOTP, "security questions", static "backup codes", or SMS. If a user has a YubiKey enrolled in their SSO account but the company allows a user to get back into their account via email OTP alone, then an attacker can simply ignore the YubiKey and attack the phishing-vulnerable OTP code. Whatever strategy the company comes up with has to balance ease of use and security.

Apple has an advanced security feature called "Security Keys" that users can enroll into. In order to activate this Apple iCloud security feature, a user has to enroll two YubiKeys. Enrolling two keys allows a user to keep a secondary YubiKey in a secured, static location, like in a fireproof box. Or better, in an off-site fireproof box. If the first key is lost, there's a second, pre-enrolled key to fall back on. Companies can do something similar: make users enroll at least two WebAuthn factors, like:

1. two or more passkeys
2. one passkey and one YubiKey, or
3. two or more YubiKeys

Users would be able to sign in with any one of those factors, and users should be forced to remove all weak factors from their SSO account.

Weak Authenticator Reset Strategies

Even with multiple WebAuthn factors enrolled, some users will still lose all their auth factors. This fact requires a thoughtful set of user support and verification policies, standards, and processes. Further in this article, I will go into more detail offering some robust authenticator reset strategies.

Work in Progress

I have more content to add to this article, but it needs to be matured before I publish it.

Thank you for reading!