Passkeys
The credential layer replacing passwords — public-key cryptography per site (WebAuthn standard), phishing-resistant by construction, no shared secret on the server. That part genuinely works. The controversy is about everything else the standard quietly enables. Anchor: nonfunctional’s “Passkeys are a trap, do not use them” (captured in full, 32 KB) — the sharpest articulation of the case against.
The trap: one name, a parts catalogue
The FIDO Alliance named many different things “passkey” — the WebAuthn spec “barely uses the term… the specs read less like a standard and more like a parts catalogue.” The axes (all presented as user choices, for now):
- Copyable vs non-copyable — can you rescue the key off a dying device, or is it sealed in?
- Transferable vs non-transferable — can it move between managers?
- Hardware-backed vs software-backed — lives in a TPM/Secure Enclave (non-extractable) or a file (exportable, shareable — the author emailed one to a friend and both could log in)
- User-present / user-verified — does login require your presence/biometric each time?
Each axis is reported to the website via authenticator data flags. And the load-bearing one:
- Attested vs non-attested — remote attestation: the site can cryptographically verify (via the tamper-proof chip) that you’re using an approved passkey manager, not custom software. Custom software can lie about every flag above — except this one. “Attestation is a part of the passkey ecosystem, whether you want it or not.”
The argument, honestly
For: passwords are genuinely broken (solarwinds123), passkeys kill phishing and credential stuffing, and TOTP — the unsung alternative the article champions — is weaker against phishing and still shares a seed with the server.
Against (the article’s case, steel-manned):
- No consumer-advocacy members in the FIDO Alliance (vs W3C’s public-interest seats) — “nobody is there to make a strong case for the user’s own interests.” The member incentives (banks’ indemnity, governments’ tracking, Netflix’s account-sharing war) don’t include your portability.
- The boiling frog: expect “very few constraints at first, then more, staggered across sites, and in a few years people will forget they were ever offered a choice.” The dial only turns one way — a passkey made non-copyable/attested can’t be made free again by the user.
- The endpoint: preventing you from running unapproved software. Attestation generalizes beyond credential managers — verifying your device “is not capable of sending encrypted messages, running a competitor’s app, or using social media without ID verification.” The author’s line: “I rather like deciding for myself what software I approve of.”
- TOTP already exists as the open, user-controlled stopgap (RFC 6238 — any software, any device, shareable seeds, no phoning home), and gets no FIDO marketing.
The practical stance
Between the poles: passkeys’ crypto is real, but prefer software-backed, exportable/synced passkeys in a manager you control (vault — same lane as password storage); treat hardware-bound/attested-only flows as lock-in signals; keep TOTP as the fallback; and watch the ratchet — the moment “your passkey isn’t secure enough, download our app” appears, that’s the attestation dial turning. For the homelab lane: self-hosted auth (kanidm (OSS) is already vaulted) keeps the credential layer user-owned.
Kin
- Supply Chain Security — trust and verification doctrine; attestation is verification pointed at the user
- LLM security — the adjacent security lane
- Agent-accessible product — auth as API surface