AI
Why Passkeys Are Replacing Passwords
Passkeys are bound to the origin they were created for. A phishing site at abc.com cannot trigger credentials registered at xyz.com. The private key never leaves the device, so a server breach exposes only public keys. These properties explain why major companies are moving users away from passwords. But passkeys have not faced decades of adversarial research the way passwords have. The researchers argue it is time to apply the same scrutiny to WebAuthn that attackers have long applied to passwords.
How WebAuthn Registers and Authenticates a Passkey
Registration starts when a user clicks “create a passkey.” The server returns a challenge. The browser calls navigator.credentials.create, which triggers the authenticator to prompt for a biometric or PIN. The authenticator generates a key pair, stores the private key, and returns the credential ID, public key, and a counter. The counter increments on every use, blocking replay attacks. Authentication mirrors this flow but calls navigator.credentials.get instead, and the authenticator signs the server’s challenge with the stored private key.
The Browser as the New Trust Anchor
With passwords, both user and server share a secret. With passkeys, trust shifts to the device. The server stores only a public key and validates a cryptographic result. It does not verify how that result was produced. The authenticator has no context about application logic. The browser sits in the middle, and developers trust it to enforce the standard. If the browser is compromised, the server accepts whatever it sends, because a valid signature is all it checks.
Forging a Passkey with a JavaScript Proxy
The extension overwrites navigator.credentials.create and navigator.credentials.get. When a user registers, the extension generates its own key pair, creates the attestation, and stores the private key. No biometric fires. The website receives a valid-looking response. On webauthn.io, registration and authentication both succeeded. On Gmail, the extension spoofed an iCloud authenticator GUID, so Gmail displayed the passkey as iCloud-managed. Logging out and back in worked without issue. From there, the attacker can change the account password and take full control.
Silent Mode, Force Reset, and Cross-Device Replay
Silent mode calls the original navigator.credentials.create but discards its response. The user sees the Touch ID prompt. iCloud stores a passkey. The extension stores a different one. The victim’s keychain shows a passkey registered, but it is the wrong one. A force-reset variant intentionally fails authentication so the user re-registers while the extension intercepts. To replay on another device, the stolen key syncs to a remote API endpoint. The attacker installs the same extension, loads the synced credential, and logs in.
Mitigations for Developers, Users, and Enterprises
Content Security Policy blocks the XSS injection path. Trusted Types API enforces sanitization before DOM insertion. Relying parties should validate more than the AAGUID — full certificate verification matters. Monitor passkey usage the same way suspicious password logins trigger step-up authentication. For users, audit installed extensions and note which ones hold host permission. That permission is standard for Grammarly and password managers, which is why it draws no attention. Enterprises can enforce approved-extension allowlists via browser management policies.
Notable Quotes
What if your browser is lying to you? Jonny Lin · ▶ 12:23
It’s like a magic box for most websites. Shourya Pratap Singh · ▶ 5:23
this pass key was never actually used Shourya Pratap Singh · ▶ 21:27
Key Takeaways
- The browser’s credentials API can be fully proxied with a few lines of JavaScript.
- A valid cryptographic signature is all a relying party checks; it does not verify origin.
- Silent mode leaves no visible trace: Touch ID fires, but the extension controls the response.
- Stolen passkey material syncs to an attacker’s server and replays on a separate device.
- Host permission, required by most extensions, is sufficient to execute this attack.
About the Speaker(s)
Shourya Pratap Singh is a principal software engineer at SquareX focused on browser extension security and web security research. He has presented at the DEFCON main stage, Recon Village, Adversary Village, and Black Hat Arsenal EU, and has delivered workshops at the Texas Cyber Summit. He holds a degree from IIIT Bhubaneswar and a patent in his field.
Jonny Lin is a frontend engineer on the SquareX extension team, working on browser security problems including data loss prevention and web-based vulnerability detection. Before SquareX he was a founding engineer at Velt (YC W23). He holds a computer science degree from Santa Clara University.
Daniel Seetoh is a senior frontend engineer at SquareX, where he works on the browser extension and web application. He holds degrees from Nanyang Technological University and focuses on building products that deliver direct security value to users.