Don't use passkeys for encrypting user data

Original Article ↗ Hacker News Discussion ↗

Authentication vs Encryption & PRF

  • Many comments stress a core category mistake: treating authentication credentials (resettable) and encryption keys (irreplaceable) as interchangeable.
  • With WebAuthn PRF, a passkey can silently become the basis for an encryption key; if the passkey is lost or deleted, encrypted data is gone.
  • Some suggest “right” designs: per-file/backup encryption keys, each wrapped for multiple passkeys, or PRF-derived keys only as one of several decryption paths.
  • Others argue this is still fragile at scale; for true E2EE, passkeys should never be the only key.

Risk of Loss, Recovery, and User Behavior

  • Commenters disagree whether users will actually delete passkeys “for cleanup,” but multiple anecdotes show people deleting credentials they don’t recognize.
  • Users often don’t know where passkeys live (OS store vs browser vs password manager), or that deletion can cause permanent data loss.
  • Even technical users report accidental overwrites when sites and managers mishandle multiple passkeys per account.
  • Several emphasize: for any E2EE scheme, a fraction of users will always lose keys; passkeys can reduce but not eliminate this.

UX, Implementation, and Cross‑Platform Issues

  • Many describe passkey UX as opaque and inconsistent: different behavior across OSes, browsers, embedded webviews, and password managers.
  • Examples include: sites that only accept PRF-capable passkeys; broken flows on Firefox/Linux; confusion over which device/provider holds the key; Amazon‑style prompts that still ask for 2FA and then “create a passkey” again.
  • Some prefer passkeys stored in cross‑platform managers (Bitwarden, KeePassXC, Vaultwarden) to avoid Apple/Google lock‑in, but note these are second‑class citizens in the ecosystem.

Passkeys vs Passwords, 2FA, and Hardware Keys

  • One camp: strong passwords + password manager + TOTP/hardware 2FA are simpler, portable, and well‑understood; passkeys add complexity for marginal gain.
  • Another camp: passkeys are substantially more phishing‑resistant and, when synced, reduce key‑loss compared to user‑managed E2EE keys.
  • Debate over whether passkeys are “1FA only” or effectively 2FA (device + biometric); some SaaS treat them as 2FA replacements, which others call a conceptual mistake.
  • Hardware keys (U2F/FIDO) are widely praised as conceptually clear (“a physical key for your account”) but seen as too expensive and cumbersome for mass adoption.

Privacy, Attestation, and Lock‑In Concerns

  • Some argue hardware attestation could be used to lock services to specific OS/browser stacks and block open implementations or exportable managers.
  • Others counter that mainstream synced passkeys don’t use attestation, and its real purpose is enterprise control over which authenticators employees can use.
  • There is tension between making secrets non‑exportable (for phishing resistance) and giving users tangible, backup‑able keys they can understand and control.

Adoption, Policy, and Who Passkeys Are For

  • Several worry about forced passkey adoption (e.g., some financial services), especially where platform support is flaky.
  • Older and non‑technical users are seen as especially vulnerable to lockouts, given reliance on a single phone and weak backup habits.
  • A recurring sentiment: passkeys solve real problems, but current specs, tooling, and education are not yet good enough for them to be safely used as sole keys for long‑lived encrypted data.