Passkeys are not a trap

Original Article ↗ Hacker News Discussion ↗

Passkeys—passwordless logins based on public‑key cryptography—are being promoted as a more secure, phishing‑resistant alternative to passwords and TOTP codes, but their real‑world impact remains contentious. Commenters weigh security benefits and convenience (especially when synced via major ecosystems or password managers) against serious concerns over vendor lock‑in, attestation being used to exclude open or self‑hosted solutions, confusing multi‑device UX, and account‑recovery failure modes. Many conclude passkeys are promising in tightly managed corporate or single‑vendor environments, yet risky or premature as a universal replacement for passwords and traditional 2FA.

Scope of debate

  • Most commenters accept that passkeys are technically sound public‑key auth, but dispute whether the current ecosystem and standards are user‑friendly or safe from abuse.
  • The thread largely focuses on: attestation and lock‑in risk, portability, UX failures, and differing threat models versus passwords+TOTP.

Attestation, lock‑in, and “trap” concerns

  • WebAuthn attestation lets sites know the authenticator model (AAGUID) and potentially restrict which authenticators are allowed.
  • Critics argue this is a “dial” that can be turned later: start with permissive settings, then gradually require attested, vendor‑approved authenticators.
  • Concrete examples cited:
    • Corporate Microsoft Entra setups only allowing Microsoft Authenticator.
    • Swiss and Austrian e‑ID systems whitelisting a few hardware tokens.
    • A FIDO participant threatening that non‑compliant KeepassXC behavior could lead to it being blocked by relying parties.
  • Supporters counter: mainstream consumer platforms currently return none and large sites would not risk instantly locking out users; some major vendors publicly discourage attestation for consumer sites.
  • Skeptics reply that “not used yet” doesn’t remove the capability, and standards can evolve under commercial or regulatory pressure.

Portability, ecosystem lock‑in, and backups

  • Experience is highly inconsistent across Apple, Google, Microsoft, browsers, and password managers.
  • Some report smooth migration (e.g., Apple ↔ 1Password/Bitwarden, CXF/CXP specs), others find:
    • No generic export, only app‑to‑app transfers to a closed whitelist of apps.
    • Hardware/software being explicitly rejected (e.g., Bitwarden, KeePassXC, Linux+Firefox).
  • Many fear dependency on a single cloud account (iCloud/Google) and vendor lockout scenarios; they value being able to print or self‑archive passwords/TOTP secrets.

Security benefits vs passwords/TOTP

  • Pro‑passkey arguments:
    • Strong phishing resistance: keys are bound to domains and can’t be replayed or leaked like passwords or TOTP codes.
    • Server leaks expose only public keys; no password cracking.
    • For non‑technical users who reuse passwords and fall for phishing, this is a major real‑world win.
  • Skeptical views:
    • Good password managers with unique passwords and TOTP already mitigate most risk; for such users, added benefit is marginal.
    • Attacks on passkey ecosystems exist (password reset/enrollment phishing, buggy implementations, device compromise, “pass‑the‑key” style issues).
    • Recovery flows and secondary factors (email/SMS, backup codes) remain phishable, so phishing isn’t eliminated, just shifted.

Usability, recovery, and threat models

  • Many report passkeys as a “confusing mess”:
    • Multiple competing “managers” per device; unclear where a credential is stored.
    • Broken or incomplete support on Linux, VMs, remote desktops, or Bluetooth‑less machines.
    • Sites mishandling multiple passkeys, mixing passkey with existing password+2FA in strange ways, or forcing enrollment with dark patterns.
  • Loss and recovery:
    • People worry about losing all devices, vendor account lockouts, or cross‑platform moves (iOS→Android, corporate vs personal accounts).
    • Hardware‑only or attested flows raise fears of irreversible lockout, versus today’s ability to keep paper backups and migration‑friendly password stores.
  • Threat models differ:
    • Some prioritize phishing and commodity attacks → favor passkeys.
    • Others prioritize control, anonymity, resilience against vendor misuse or state coercion → favor passwords+TOTP and self‑managed keys.

Enterprise vs consumer split

  • In corporate environments, many report successful Yubikey/passkey rollouts with strong central recovery, and users are happy to ditch passwords.
  • The main anxiety is about these enterprise‑style controls (attestation, whitelists, mandatory proprietary apps) being applied to consumer banking, government, and “must use” services.

Overall sentiment

  • Enthusiasts: passkeys are a clear upgrade, especially with a good cross‑platform password manager; fears about attestation are overblown.
  • Skeptics: passkeys embed new power for platforms and relying parties, UX is brittle, portability is constrained, and the “future dial‑turning” risk makes them a potential long‑term trap.