WebAuthn and Passkeys

Inspecting WebAuthn Traffic

Just released v2 of a Chrome Extension that overrides the navigator.credentials.get and navigator.credentials.create endpoints to show the json that is sent and received from a webauthn transaction. The extension simply produces a dialog box that shows the json submitted to the appropriate endpoints on a server that supports Passkeys. It’s available as an unpacked Chrome extension at https://github.com/krypted/webauthn-inspector.

The two primary attributes I was interested in exploring are “id” and “challenge”. Visit webauthn.info and change the “Advanced Settings” it’s easy to see how the other fields change as the settings change and compare these to sites (e.g. bestbuy.com) that have implemented some of the WebAuthn spec. In general, the id remains static while the challenge changes based on the spec explained at webauthn.guide.

Most browsers support similar javascript based extensions (e.g. Firefox and Safari) so feel free to make a pull request if you can get this working for those (I’ll tinkerate with the webkit entitlement to see if I can get this to work in Safari at some point). Further, this is distributed unpacked but even I an extension is a crx, it’s easy to extract and download an extension to see what it does, as seen with this extension: https://chrome.google.com/webstore/detail/crx-extractordownloader/ajkhmmldknmfjnmeedkbkkojgobmljda?hl=en-US. Any extension that touches the navigator.credentials.* functions should be viewed with suspicion. Heck, any browser extension should be for that matter… For example, use this one I did awhile back to just find and replace words on a web page to see how much of the content rendered on a page they have access to: https://github.com/krypted/Word-Replacer-Safari-Extension. If they can also POST or GET to an endpoint somewhere then the extension can send data rendered to a third party.

While the underlying derived credentials flow in WebAuthn is as secure as it gets for the most part, we still don’t want the id and challenges falling into the wrong hands. They still harken back to a public/private keypair, just with larger credentials dynamically generated and encrypted with a token based on a biometric-based key, masquerading behind marketing speak from hastily implemented development teams as something else. It’s all still effectively Euclidian geometry that can be reversed with powerful enough systems and enough time to do so (which is hopefully longer than the life of the computer that hosts the key, given that a new key is generated on each device). Or that was the plan until they could be sync’d… But now I’m just rambling. Hope the extension is useful to others in their research endeavors.