DEV Community

Om Bhamare
Om Bhamare

Posted on

Beyond the Password: How Passkeys Work Under the Hood

#security #cryptography

Passwords are broken. They get leaked in database breaches, reused across platforms, and phished through clever domain spoofs. While Multi-Factor Authentication (MFA) helps, standard SMS or OTP codes still leave major security gaps.

Enter Passkeys: a modern authentication standard built on top of WebAuthn and FIDO2 specifications designed to eliminate shared secrets entirely.

Here is a dive into the underlying cryptography, architectural flow, and why passkeys are inherently phishing-proof.

The Core Concept: Asymmetric Cryptography

Traditional authentication relies on shared secrets. Both you and the server know your password (or a hashed version of it). To verify who you are, you send that secret over the network.

Passkeys replace shared secrets with asymmetric (public/private key) cryptography:

  • Private Key: Generated locally on your device and stored inside a Hardware Security Module (like Apple's Secure Enclave, Android's Titan chip, or a YubiKey) or an end-to-end encrypted sync service (iCloud Keychain, 1Password, Google Password Manager). It never leaves your device unencrypted.
  • Public Key: Registered with and stored by the website (the Relying Party). It is completely public and mathematically useless to an attacker on its own.

Architectural Breakdown: How It Works

Passkey operations consist of two cryptographic phases: Registration and Authentication.

Phase 1: Registration (Generating the Keypair)

When you create a passkey for a service (e.g., app.example.com):

  1. Challenge Request: Your client initiates registration. The server generates a cryptographic challenge (a high-entropy random string) and sends it back alongside origin metadata (RP ID).
  2. Local Verification: Your browser hands this request to the OS/authenticator, which prompts for user verification—biometrics (Face ID/Touch ID/Windows Hello) or a hardware PIN.
  3. KeyPair Generation: Once unlocked, the hardware generates a unique keypair bound exclusively to app.example.com.
  4. Public Key Registration: The private key is saved locally. The public key, along with an attestation signature, is returned to the server and stored in your user record. 
+--------+                 +---------+                 +-------------------+
| Device |                 | Browser |                 | Server (RP)       |
+---+----+                 +----+----+                 +---------+---------+
    |                           |                                |
    |                           |<-- 1. Request Reg + Challenge -|
    |                           |                                |
    |-- 2. Biometric Unlock -->|                                |
    |-- 3. Gen Keypair ------->|                                |
    |                           |-- 4. Public Key + Signature -->|
    |                           |   (Stored in DB)               |
Enter fullscreen mode Exit fullscreen mode

Phase 2: Authentication (Challenge-Response)

When you return to log in:

  1. Authentication Request: You provide your username. The server generates a new, time-bound random challenge string.
  2. Domain Matching: The browser checks the requesting domain against the stored domain origin associated with the private key.
  3. Local Authorization: The OS prompts for your biometric or PIN to consent to the operation.
  4. Digital Signing: The authenticator uses your private key to digitally sign the server’s challenge along with contextual data (authenticatorData).
  5. Server Verification: The signature is sent to the server. The server uses your previously stored Public Key to decrypt and verify the signature. If it matches, you are logged in.

Why Passkeys Beat Passwords and Standard MFA

Threat Traditional Passwords Passkeys
Phishing / Lookalike Domains Vulnerable (Users enter credentials on fake sites) Immune (Browser enforces RP ID matching)
Server Data Breaches Vulnerable (Hashes can be cracked) Immune (Public keys are useless to attackers)
Man-In-The-Middle (MitM) Vulnerable Immune (Signed challenges prevent replay attacks)
Credential Stuffing Vulnerable Immune (Keys are unique per site)

The Secret Weapon: Origin Binding

The single greatest architectural feature of WebAuthn is Origin Binding.

If an attacker sets up a perfect replica site at examp1e.com and tricks you into logging in:

  1. The fake site forwards the challenge from the real server to your browser.
  2. Your browser evaluates the actual URL in the address bar (examp1e.com) against the domain bound to your key (example.com).
  3. The browser refuses to sign the challenge.

Because this check happens at the browser/OS layer, human error is removed from the security equation entirely.

Summary

Passkeys shift the burden of security from user memory to cryptographic verification. By combining hardware-backed asymmetric keys with origin-bound browser enforcement, passkeys make credential theft, phishing, and server-side breach vectors relics of the past.

Top comments (0)