Webauthn

Source: “Webauthn, Passkeys, and You - The Future of Authentication” - William Brown (Everything Open 2023) link

url: https://www.youtube.com/watch?v=V-7zMIgGO1U
title: "\"Webauthn, Passkeys, and You - The Future of Authentication\" - William Brown (Everything Open 2023)"
description: "(William Brown) Many people and businesses are starting to talk about Passkeys, Webauthn, FIDO and more. With a veritable tsunami of jargon in the space it c..."
host: www.youtube.com
favicon: https://www.youtube.com/s/desktop/024ccc3d/img/logos/favicon_32x32.png
image: https://i.ytimg.com/vi/V-7zMIgGO1U/maxresdefault.jpg?sqp=-oaymwEmCIAKENAF8quKqQMa8AEB-AH-CYAC0AWKAgwIABABGFQgZShZMA8=&rs=AOn4CLCdkpuBFdcArkhnsAF3Swi6I9Hg1Q

Date of Presentation: Recorded, October 2023 Presenter: William Brown, Senior Software Engineer at SUSE Labs

Executive Summary

William Brown’s presentation provides a deep dive into WebAuthn and passkeys, clarifying concepts, dispelling common misconceptions, and highlighting both the security advantages and the practical implementation challenges. The key takeaway is that WebAuthn, and passkeys built on it, represent a significant improvement over traditional password-based authentication due to their inherent resistance to phishing and their use of cryptographic principles. However, the implementation can be complex and requires careful attention to the nuances of the standard and the specific libraries used. This talk serves as an informative guide for both the technically curious and developers looking to implement WebAuthn into their systems.

Key Themes & Concepts

1. What are Passkeys?

• Lack of Clear Definition: There isn’t a singular, universally accepted definition of a “passkey.” The term initially seemed like a marketing term.

• Evolving Definitions: The definition has evolved over time and now has multiple meanings:

1. All possible WebAuthn authenticators, including physical security keys (like YubiKeys), fingerprint readers, and other biometric authenticators.

2. Synchronized credentials that are synced across devices via an account-based key chain (e.g., iCloud Keychain).

3. Resident Keys (Discoverable Credentials). According to the speaker, this definition is “less desirable” due to limitations and potential harm that arise from only using resident keys. (Apple’s iCloud ecosystem, by default, tends to create resident keys, though this may change over time.)

2. WebAuthn Workflow

• Three Key Components: WebAuthn involves a “relying party” (the website), a “client” (the web browser), and an “authenticator” (the hardware device or secure element).

• Challenge-Response: The website sends a challenge to the browser; the browser interacts with the authenticator; the authenticator signs the data using its private key; and the signature is sent back to the website to verify the authentication.

• Asymmetric Cryptography: WebAuthn uses public/private key cryptography, similar to smart cards or PIV. The private key resides in the authenticator, and the public key is used by the relying party to verify the signature.

• Compromise Resistance: Unlike passwords, compromising the relying party’s database doesn’t give attackers the user’s private key or a way to impersonate the user.

3. Multi-Factor Authentication with WebAuthn

• PIN/Biometric Verification: The PIN or biometric verification on the authenticator device is essential; physical interaction is part of the authentication.

“The browser actually contacts the device over USB, and in that request sends the PIN that you typed in into the authenticator. The authenticator validates that PIN is correct, and if that PIN is not correct, it will not proceed. Only if that PIN is correct will it proceed.”

“When the request is sent into the device, the fingerprint is requested on the device, and when you put your fingerprint on the reader, the act of putting your finger on the reader is not only the interaction required to prevent malware but also validates your fingerprint.”

• Secure Enclaves: Devices with secure enclaves cannot be circumvented by the operating system; the fingerprint data never leaves the device.

4. Multi-Device Credentials

• Synchronization: Private keys are encrypted and synchronized across devices associated with the user’s account (e.g., iCloud Keychain). This allows users to authenticate with various devices.

“The private key that was generated for this website on my Mac was then encrypted, put into the iCloud keychain, and only other devices in my account can download and decrypt that private key.”

• Bluetooth and QR Codes: A QR code can trigger a Bluetooth Low Energy connection, enabling a phone to help authenticate a browser session on another device.

5. Phishing Resistance

• Domain Name Binding: A key strength of WebAuthn is its inherent resistance to phishing. The domain/origin of the website is included in the data signed by the authenticator.

“The step that matters to prevent phishing within WebAuthn and passkeys is at this stage here, between the collected client data from the browser and how it is sent into the authenticator.”

• Origin Verification: The browser sends the authenticator the exact bytes of the origin (domain), ensuring the user is authenticating at the intended website.

“The origin comes from the browser, not the relying party, which makes it much harder to tamper with.”

• Signature Validation: A signature is created by the device that includes the origin, so a phishing site’s signature will fail on the real site.

6. Key Management & Storage

WebAuthn credentials can be resident (discoverable) or non-resident (non-discoverable), each with distinct implications.

• Non-Resident (Non-Discoverable) Keys:

• Typically, the authenticator stores only a small wrapped key reference. The user’s handle (username) and credential ID primarily live on the server side.

• Minimal On-Device Storage: Although each new non-resident credential requires some space, it is very small—often just enough to store an index or wrap of the key. Hence, an authenticator can support hundreds or even thousands of non-resident credentials in many cases.

• Requires Username or Account Lookup: The relying party (server) must send the correct credential ID to the authenticator during login. The user generally types a username, and the server does the rest.

• Better Privacy: The authenticator won’t reveal credential existence unless given the exact credential ID.

• Resident (Discoverable) Keys:

• The authenticator stores key material plus user metadata (e.g., a user handle or username) directly, enabling “username-less” flows.

• Easier User Experience (UX): Users can simply select the account on their device without typing a username.

• Higher Storage Usage: Some devices have extremely limited capacity for resident keys (e.g., 0, 8, or 32). Others, like modern laptops or phones, may store many more.

• Potential Privacy Trade-Offs: The authenticator can reveal that a credential exists, unless carefully controlled with user consent.

Negative Impacts of Resident Keys Highlighted by the Speaker:

1. Limited Storage: Physical security keys (such as some CTAP2 devices) might allow only a handful of resident credentials (sometimes 0, 8, or 32).

2. Inability to Delete Keys: Certain devices do not allow deletion or modification of stored credentials. This lack of manageability can harm users who need to update or remove personal identifying information.

3. Harm to Specific User Groups: Transgender individuals or others who want to change personal information (e.g., a new name or updated user handle) may find themselves stuck with old data on devices that don’t allow deletion.

4. User Experience Issues: If a device has minimal resident key capacity or if the user is confused by the discoverable-credentials flow, it can lead to poor UX.

5. Lack of User Control: Forcing resident credentials limits users’ choices of which authenticators to use (especially those with small capacity or no deletion support).

6. No Warnings: Browsers typically do not alert users before creating a resident key, leaving them unaware of potential device storage issues or privacy concerns.

Speaker’s Position: While resident keys do enable username auto-completion, the potential harm (especially for marginalized communities or in limited-storage scenarios) often outweighs the usability benefits. For this reason, the speaker expresses a strong dislike for defining “passkeys” strictly as resident credentials.

7. Implementation Challenges

• Complexity of the Standard: The WebAuthn specification is very long and covers many use cases, which may be difficult to navigate.

“The spec for WebAuthn is trying to solve many use cases… If you have a narrow use case like passkeys or ‘I just want cryptographic auth,’ it can be hard to navigate this complex spec to make that happen securely.”

• Library Gaps: Some libraries have implementation gaps or design choices that impact security.

• Careful Implementation: Developers must understand implications of library settings such as user verification, resident key handling, and cryptographic parameters.

“You must set user verification required, else your multi-factor devices are actually single-factor.”

• Attestation: This cryptographic certificate from hardware manufacturers can identify device properties but may not always be provided.

“FIDO certification represents conformance to an API, not a representation of security or quality.”

Important Quotes

• “There is no clear definition of what a passkey is.”

• “At its core, what we’re talking about here is WebAuthn being a form of public/private key cryptography or asymmetric key cryptography.”

• “WebAuthn is not able to be phished because of these properties.”

• “The way that we allow these credentials to work with an infinite number of sites happens at this stage.”

• “If someone is able to decrypt these, then we have very significant problems in the security of cryptography on the internet as a whole.”

• “The problem is that by requesting them or forcing them outside of just opportunistic existence, we do have potential harms against people, and I don’t think that’s okay.”

• “Writing your own cryptographic code is great fun and it’s a really wonderful educational experience… but there is a big gap between writing that code for education and fun to production.”

• “FIDO certification represents conformance to an API, not a representation of security or quality.”

• “Passkeys are a self-contained multi-factor authenticator.”

Answers to Questions

1. “But even each incremental non-resident key would take some space on the device, right? Can’t be 0?”

• Yes, each new non-resident credential does consume some space, but it is extremely small (often just a wrapped key reference or index). This is significantly less than a full resident key, which needs to store user-related metadata. Hence, an authenticator can often store many non-resident keys compared to a much smaller limit for resident keys.

2. “What about passkeys that sync across multiple devices (e.g., iCloud Keychain)? Must they use resident or non-resident keys, or can they use both?”

• Most multi-device passkeys are resident (discoverable) credentials so that they can provide a seamless username-less flow. This is the simplest approach from a user-experience standpoint, which Apple and others favor.

• Technically, you could implement a “synced credential” with a non-resident key approach, but it defeats some of the frictionless UX benefits (the user would still need a username or some other lookup). So, while both are possible under WebAuthn, mainstream multi-device passkeys generally use resident keys.

3. How to Prevent User Enumeration?

• One strategy is to generate fake credential IDs for non-existent users. The server can respond with a credential ID even when the username does not exist, obscuring whether a user truly exists.

4. Why No Browser Warnings for Resident Keys?

• Most browsers do not prompt or warn before creating resident credentials, which can surprise users (or fill device storage without notice). This is a UI challenge that the speaker highlights.

5. Use Cases for Resident Keys Despite Their Downsides?

• Synchronized devices (like phone, laptop) to enable username-less sign-in.

• Username auto-completion or selection (especially on a single shared device).

• Offline devices or specialized corporate deployments where the server is not always reachable.

6. Software Keys vs. Hardware Keys?

• Software-based keys (e.g., phone-based passkeys) are still more secure than passwords, but may not be appropriate for the highest-security needs.

• Attestation can provide some control, but does not necessarily guarantee full hardware protection.

7. Attestation

• A cryptographic certificate from the authenticator manufacturer that can help verify the security properties of the device, though it is optional and can introduce privacy trade-offs.

Conclusion

WebAuthn and passkeys represent a significant step forward in secure, phishing-resistant authentication. However, as William Brown’s presentation underscores, implementing passkeys—especially those defined as resident credentials—introduces complex trade-offs around storage limits, inability to delete or update keys on some devices, and potential harm for users needing to change personal details. Non-resident credentials, while less “username-less,” can avoid some of these pitfalls by storing minimal data on the authenticator.

Developers must be careful with library choices, user verification settings, and whether they require or allow resident credentials. In most consumer-facing scenarios (like iCloud Keychain passkeys), resident keys are chosen for the convenience of synchronized, username-less flows. Yet the speaker’s cautionary notes remind us that neither approach is perfect, and real-world needs—such as supporting marginalized communities, offering true user control, or ensuring large-scale credential storage—should guide the final choice.

Despite the complexities, the speaker encourages developers to experiment with and implement WebAuthn in their own sites. Properly deployed, passkeys provide a more secure and user-friendly alternative to passwords, advancing both individual security and the broader authentication ecosystem.

Learn How to Implement Webauthn in JS

url: https://www.youtube.com/watch?v=viZs1iVsLpA
title: "How To Setup Fingerprint Auth In JavaScript"
description: "Authentication is a difficult topic especially when dealing with biometric auth and passkeys. That is until now. In this video I will explain how you can use..."
host: www.youtube.com
favicon: https://www.youtube.com/s/desktop/024ccc3d/img/logos/favicon_32x32.png
image: https://i.ytimg.com/vi/viZs1iVsLpA/maxresdefault.jpg