FIDO2/WebAuthn: Passwordless Auth Deep Dive

FIDO2 and WebAuthn aren’t just about ditching passwords; they’re a fundamental shift in how the internet proves who you are, moving from shared secrets to unique, unforgeable digital identities.

Let’s see this in action. Imagine logging into a service that supports FIDO2.

User’s Machine (Browser/OS):

1. You initiate a login.
2. Your browser, via the OS, asks your FIDO authenticator (like a YubiKey or your phone’s fingerprint sensor) to sign a challenge.
3. Your authenticator uses its private key to sign the challenge. This private key never leaves the authenticator.
4. The signed challenge is sent back to the server.

Server:

1. Receives the signed challenge.
2. Uses the corresponding public key (which it stored during registration) to verify the signature.
3. If valid, you’re logged in.

This process is governed by two main specifications:

• FIDO2: The overarching project by the FIDO Alliance for passwordless and strong authentication. It includes the Client-to-Authenticator Protocol (CTAP) and the WebAuthn API.
• WebAuthn (Web Authentication API): A W3C standard API that browsers implement. It allows websites to programmatically create and use FIDO credentials. It’s the bridge between your website and your FIDO authenticator.

The Problem FIDO2 Solves: The Password Apocalypse

Passwords are the weakest link in online security. They’re:

• Easily Phished: Users are tricked into revealing them.
• Reused: If one site is breached, attackers try those credentials everywhere.
• Weak: Many are simple, guessable, or easily brute-forced.
• A Usability Nightmare: Complex password policies lead to forgotten passwords and resets.

FIDO2 tackles this by replacing shared secrets with public-key cryptography tied to a physical or biometric authenticator.

How it Works Internally: Registration and Authentication

1. Registration:

   • When you register a FIDO authenticator with a website, your browser (using WebAuthn) requests the creation of a new credential.
   • Your authenticator generates a unique, random public/private key pair for that specific website. The private key is stored securely on the authenticator and never exported.
   • The authenticator returns the public key and a credential ID (a unique identifier for this key pair on this site) to the website.
   • The website stores your credential ID and the corresponding public key.

2. Authentication:

   • When you log in, the website sends a challenge (a random string of data) and the credential ID you’re trying to use.
   • Your browser, via WebAuthn, asks the authenticator associated with that credential ID to sign the challenge.
   • The authenticator uses its stored private key to sign the challenge.
   • The browser sends the signed challenge back to the website.
   • The website retrieves your stored public key using the credential ID, and verifies the signature on the challenge. If the signature is valid, you’re authenticated.

Key Levers You Control (as a developer/administrator):

• navigator.credentials.create() (Registration): This WebAuthn API call is how you initiate the process for a user to register a new FIDO credential. You specify options like challenge, rp (relying party/your site’s info), and user info.
• navigator.credentials.get() (Authentication): This API call initiates the login flow. You provide challenge, rpId, and allowCredentials (a list of credential IDs to try).
• Relying Party ID (rp.id): This is your domain name (e.g., login.example.com). It ensures the authenticator only signs challenges for your domain, preventing credential theft by spoofed sites.
• User Verification (authenticatorSelection.userVerification): This can be set to required, preferred, or discouraged. required means the user must verify their identity on the authenticator (e.g., fingerprint, PIN) for the operation to complete.
• Attestation (attestation): During registration, you can request attestation. This provides the website with information about the authenticator itself (e.g., its vendor, model, whether it’s a platform authenticator like a phone or a roaming authenticator like a YubiKey). This is useful for security analysis or enforcing policies on authenticator types.

The most surprising part about FIDO2 is how it leverages existing public-key cryptography infrastructure, but in a way that’s entirely invisible to the end-user and fundamentally unbreakable by traditional credential stuffing attacks. The private keys are generated and stored client-side, meaning they never traverse the network, thus eliminating the primary vector for credential theft.

The next hurdle you’ll likely encounter is implementing secure credential management for users who have multiple authenticators or lose access to one.