A Tour of WebAuthn

Original Article ↗ Hacker News Discussion ↗

Value of the write-up / learning resources

  • Many find the article unusually clear and code-focused compared to the dense, hyperlink-heavy WebAuthn specs.
  • Some report it finally helped them understand evolving standards (U2F → FIDO2 → WebAuthn → passkeys).

Complexity and usability of WebAuthn

  • Several commenters view WebAuthn/passkeys as over-complex and “enterprise-shaped,” with ease of implementation seemingly a low priority.
  • Complaints include confusing UX around registration, credential discovery, authenticatorAttachment, and inconsistent site flows.
  • There’s frustration that WebAuthn is tightly tied to browser JavaScript APIs with no simple non-browser/CLI path.

Passkeys, syncing, and user control

  • Big concern: synced, “discoverable” passkeys feel paternalistic and lock users into vendor ecosystems and paid sync services.
  • Lack of robust export/import at launch is widely seen as user-hostile; some expect eventual export but fear “approved provider” lock-in.
  • Others note local/no-sync implementations exist (e.g., password-manager-based or self-hosted vaults) and argue “you have to trust something,” though some strongly reject needing to trust any online sync.

Hardware tokens vs software and key management

  • Debate over resident (discoverable) vs non-resident credentials:
    • Non-resident hardware keys praised for phishing-resistant MFA without capacity worries.
    • Resident keys introduce storage limits and management pain (deleting individual credentials, full slots, needing multiple keys).
  • Newer hardware supports more resident keys and credential management, but UX is still considered clunky.

Security comparisons: passwords, OTP, WebAuthn

  • Some argue strong, unique passwords plus TOTP is a practical “sweet spot.”
  • Others emphasize TOTP/SMS are phishable and replayable; WebAuthn’s URL-bound, non-replayable design is seen as a major security upgrade.
  • Push-based MFA and “pick the right number” flows are criticized as vulnerable to MFA fatigue and social engineering; “type this number in” is seen as slightly better but still phishable.

Standards process, power, and attestation

  • Strong skepticism that WebAuthn/passkeys are corporate-driven and user-controlling.
  • Others counter that work happened in public (W3C lists, GitHub), though dominated by big companies.
  • Attestation is controversial:
    • Critics say it lets sites whitelist/blacklist authenticators, undermining user freedom.
    • Others claim major platform passkey implementations have effectively dropped attestation for synchronized credentials, limiting this risk, though references show attestation still exists in some non-passkey or enterprise/MDM contexts.

Implementation pitfalls and tooling

  • Noted registration edge case: credential created on client but never recorded server-side (network failure) leading to “split brain” where authenticator thinks it works but server does not. A proposed “Signals API” aims to address this; implementation status is mixed.
  • Chrome DevTools’ virtual authenticator is suggested for testing, but there’s no simple curl-style tool for WebAuthn flows.

Adoption trade-offs and user behavior

  • Some see passkeys as clear progress and already use them alongside passwords for convenience.
  • Others refuse to use services that drop passwords, or view passkeys as a “manufactured solution” that centralizes control and complicates recovery and portability.