Passkeys: Phishing-Proof Login

01 The problem only passkeys solve

Recall Lesson 8's honest admission: magic links and OTP are still phishable, because a human can be tricked into relaying the secret to a fake site. The root cause is universal to every shared-secret method: if there's a secret the user can transmit, they can be fooled into transmitting it to the wrong party. Passwords, OTPs, even SMS — all share this. Passkeys break the pattern by never transmitting a secret at all.

02 The core swap: public-key crypto (the mirror of Lesson 4)

Passwords and passkeys are opposites. With a password, you send the secret and the server stores a hash of it — so the server holds something worth stealing, and you hand the secret over every login. With a passkey, the secret (private key) never leaves your device, and the server stores only the matching public key — which is useless to a thief.

03 The two ceremonies

WebAuthn has exactly two flows. Both are a challenge the authenticator answers — the difference is whether you're creating the key pair or using it.

04 🎯 Your tangible win (5 min): generate a passkey, defeat a phisher

A zero-dependency lab runs the whole ceremony with a real P-256 key pair (the WebAuthn default), then stages a phishing attack and a replay attack against it.

# in your terminal (no npm install needed):
cd ~/projects/learn/public/courses/auth/practice/passkey-lab
node demo.js

login on the REAL site → ✅ {"loggedIn":true}

🎣 user phished on https://app.evil.example — the device DOES sign, but:
  signed for origin: https://app.evil.example
  🛡️ origin mismatch: signed for "app.evil.example", expected "app.example"

🔁 attacker replays a captured valid assertion:
  🛡️ stale/replayed challenge

05 Why phishing is impossible here (the two guarantees)

06 In practice: don't hand-roll it

The lab simplifies (real WebAuthn signs authenticatorData + a hash of clientDataJSON, with attestation, signature counters, and CBOR encoding). You should never implement the byte-level verification yourself — use a vetted library. In Node that's @simplewebauthn/server, and the shape is small:

const { generateRegistrationOptions, verifyRegistrationResponse,
        generateAuthenticationOptions, verifyAuthenticationResponse } = require('@simplewebauthn/server');

// REGISTER — server issues options (incl. a challenge); browser calls navigator.credentials.create()
app.post('/register/options', async (req, res) => {
  const options = await generateRegistrationOptions({
    rpName: 'MyApp', rpID: 'app.example', userName: req.user.email });
  req.session.challenge = options.challenge;             // remember it to verify next
  res.json(options);
});
app.post('/register/verify', async (req, res) => {
  const v = await verifyRegistrationResponse({ response: req.body,
    expectedChallenge: req.session.challenge,
    expectedOrigin: 'https://app.example', expectedRPID: 'app.example' });
  if (v.verified) await db.saveCredential(req.user.id, v.registrationInfo); // store PUBLIC key + credId
  res.json({ ok: v.verified });
});
// LOGIN mirrors this: generate/verifyAuthenticationResponse, then req.session.userId = user.id  ← the handoff

07 Check yourself

08 Where we go next — and how far you've come

That's the modern endgame: a login with no shared secret, immune to phishing and replay, leaking nothing on breach. Step back and look at the whole map you've built — you can now place any auth system on it:

Lesson 10 is the capstone: a decision framework — given a real app, which methods do you combine, where does each token live, and how do you wire it in Express end to end — turning this map into a build you can ship.

💬 Ask me anything — e.g. "stand up a real @simplewebauthn demo I can use with Touch ID", "how do synced vs device-bound passkeys differ?", or "design the recovery flow." · Back to Lesson 8 · Lesson 3 · Resources.