Passkeys and WebAuthn explained: the end of passwords

Apple, Google and Microsoft have spent years pushing in the same direction: eliminating passwords. The technology making it possible — passkeys, built on the WebAuthn/FIDO2 standard — is already live on major platforms and thousands of services. It's not a rebrand of "sign in with Google": it's public-key cryptography applied to login, working radically differently from everything before it.

The structural problem with passwords

Passwords fail by design, not by careless use:

• They can be phished: if a user types one into a fake site, the attacker has it.
• They can leak: any compromised database exposes verifiable material.
• They get reused: one minor-service breach compromises major accounts.
• Memorable or strong, rarely both — tension resolved by managers, which still depend on a master password.

Every historical fix (SMS 2FA, secret questions, forced rotation) added friction without closing the fundamental hole: a shared secret travels from your brain to the server.

The model change: never send the secret

A passkey replaces the shared secret with an asymmetric key pair generated on your device:

1. At registration, your device generates a unique pair for that site: a private key that never leaves it, and a public key handed to the server.
2. The server stores only the public key, tied to your account.
3. At every login, the server sends a random challenge; your device signs it with the private key and returns the signature.
4. The server verifies the signature with the public key. Valid = you.

The server never sees secret material. A full database breach yields public keys — useless for logging in, just like a properly computed hash, except here there isn't even a password to steal.

Why they can't be phished

This is the revolutionary property, born from two combined mechanisms:

Origin binding: the credential is tied to the real domain (RP ID). Phishing at secure-bank.xyz asking for bank.com credentials simply fails — the browser refuses to sign because origins don't match. The user doesn't need to detect the scam: there is technically nothing to hand over.

Local verification: signing requires unlocking the device (fingerprint, FaceID, PIN). Classic "type your password here" phishing has no analog — no typeable secret exists to transfer.

Measured results from the platforms themselves: near-zero phishing success rates against passkeys, versus millions of accounts compromised yearly with passwords+SMS.

Sync: the key to real adoption

The original FIDO critique was legitimate: credentials trapped in one device = losing your phone loses your account. Platforms solved it with E2EE sync:

• iCloud Keychain (Apple): passkeys replicate encrypted across iPhone, iPad and Mac.
• Google Password Manager: same via Google account, on Android and Chrome.
• Third-party managers (1Password, Bitwarden, Dashlane): portable passkeys across platforms and browsers.

The standard also adds secure export/import (FIDO credential exchange) to avoid ecosystem lock-in. Recovery flows (multiple passkeys per account, backup devices, verified alternative channels) remain the actual work frontier — because cryptography is infallible; human logistics aren't.

Implementing it in your application

The WebAuthn browser flow:

// REGISTRATION
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,
    rp: { name: "My App", id: "myapp.com" },
    user: { id: userIdBytes, name: "ana@example.com", displayName: "Ana" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",      // discoverable: login without typing email
      userVerification: "preferred" // biometrics when available
    }
  }
});
// credential.response attestation -> send to backend, store public key

// LOGIN
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: freshServerChallenge,
    rpId: "myapp.com",
    allowCredentials: []   // empty + resident key = account autofill
  }
});
// assertion.response.signature -> verify server-side with stored public key

Backend-side, validate EVERYTHING: matching single-use challenge, exact origin (clientDataJSON.origin), RP ID, growing signature counter (detects cloned keys), and attestation format if you require specific vendors. Maintained libraries exist for every stack (@simplewebauthn, webauthn4j, py_webauthn, go-webauthn) — hand-rolling means reinventing CBOR parsing with free risk.

A sensible adoption strategy

Don't switch passwords off overnight. The migration that works:

1. Offer passkeys as an extra option after password login.
2. Prompt creation right after successful authentication (peak trust moment).
3. Allow multiple passkeys per user (laptop + phone).
4. Once registered, offer direct passkey login.
5. Eventually mark password as legacy method or remove it.

GitHub, Google and much of SaaS follow exactly this path. Users keep their password as fallback while building confidence in the new flow.

Generate strong passwords meanwhile

Until the world completes the transition, passwords still exist — and remaining ones must be unique and strong: our password generator creates strong randoms instantly, and the entropy-in-bits guide explains what makes a password strong when cryptography isn't doing the job.

FAQ

Is a passkey the same as signing in with Google? No. Federation (OAuth/OIDC) delegates identity to a third party; the passkey is yours, generated per-site, without depending on Google lending you access.

What if I lose all my devices? Depends on the service's recovery system: second device, printed backup codes, or verified alternative channels. That's why you ALWAYS register more than one passkey and save any offered recovery codes.

Do they work offline or on old browsers? They need modern browsers and OS support (all major OSes since 2022-2023). On old machines, fallback remains password+MFA — another reason not to remove them yet.

Generate strong passwords while the transition completes with our online generator, free and right in your browser.