WebAuthn: Strong Authentication vs Privacy vs Convenience

### Overview In this talk, Suby Raman, a software engineer at Duo Security, discusses WebAuthn (Web Authentication API) as a modern public-key cryptography standard designed to replace traditional passwords while balancing strong authentication, user and developer convenience, and user privacy. He explains how WebAuthn removes shared secrets from authentication workflows and evaluates the real-world trade-offs between verifiable authenticator trust and user tracking protections.

### Key Topics - **The Failure of Password-Based Authentication**: Passwords represent shared secrets that suffer from database leaks, lack of enforced transport security, unsafe reuse across sites, and susceptibility to phishing campaigns (with Duo's data showing 31% of users click phishing links and 17% submit passwords). Relying on user discipline or complex hashing/salting architectures presents systemic security risks. - **Core WebAuthn Properties**: WebAuthn provides strong authentication backed by hardware-isolated modules (such as TPMs and Secure Enclaves), origin-scoped credentials that automatically mitigate phishing across lookalike domains, and attestation mechanisms to prove key origin. - **User and Developer Convenience**: Eliminating passwords removes the mental burden on users and aids accessibility for mobility-impaired or elderly individuals using biometrics (fingerprints, facial recognition, palm scanning) or security keys. For developers, storing only public keys removes the operational complexity of managing password hashing, salting, and breach remediation. - **Privacy and Trust Trade-offs**: Because hardware interactions could allow tracking or device fingerprinting, WebAuthn requires explicit user consent (physical interaction) before executing API calls. Furthermore, browsers limit silent probing of authenticators, and users can permit or deny sharing attestation certificates and device identifiers (AAGUID).

### Technical Details - **API Registration Workflow**: A relying party calls `navigator.credentials.create()` asynchronously. The configuration contains a server-generated cryptographically random `challenge` (to block replay attacks), relying party info (`rp.id` scoped to the current origin), `user` metadata, and `pubKeyCredParams` (specifying accepted algorithms such as ECDSA represented by `-7`). The browser interacts with the authenticator to generate a private-public key pair, returning `clientDataJSON` and an `attestationObject` formatted using COSE (Concise Object Signing and Encryption). - **API Authentication Workflow**: Authentication uses `navigator.credentials.get()`. The relying party supplies a challenge and an `allowCredentials` array listing registered credential IDs. The authenticator signs over the client data and authenticator data using the stored private key, which the server verifies against the stored public key. - **Attestation Types**: - *Direct Attestation*: Supplies full x.509 attestation certificates and the Authenticator Attestation GUID (AAGUID), identifying the exact make and model. - *None Attestation*: Returned when an authenticator lacks attestation private keys or when the user explicitly blocks sharing hardware details in browser prompts. - *Indirect Attestation*: The browser substitutes an anonymized certificate/AAGUID to protect privacy while attempting verification. - **Device Loss and Recovery**: WebAuthn credentials do not sync natively across devices in Level 1; losing a platform authenticator or security key requires backup authenticators or identity proofing. Raman mentions early proposals, such as Yubico's backup authenticator restoration extension, to address account recovery.

### Takeaways WebAuthn establishes robust, phishing-resistant authentication by moving security guarantees to hardware and cryptographic pairs rather than fallible human memory. However, relying parties must carefully balance security policies against privacy and UX constraints: strictly requiring direct attestation certificates will reject built-in authenticators (such as Chrome's Touch ID integration) or privacy-conscious users who block device telemetry. Implementing WebAuthn requires organizations to decide how much explicit device trust they mandate versus prioritizing frictionless user adoption.