Passkeys have the building materials for a trap
If not trap, why trap-shaped?
A Substack article called “Passkeys are a trap. Do not use them.” by The Hack made the rounds recently. It argues that passkeys could be used to restrict the software and hardware freedoms of users by requiring attestation. I didn’t find it particularly persuasive, but it made it to the front page of Hacker News and thus some people felt the need to respond.
These responses left me less confident in the absence of a trap than the original article did. This led me to read some of the spec and the spec does provide the building materials for a trap. The one thing preventing it from being set up is the restraint of a few large implementers, which makes me wonder what the difference between a trap and this current arrangement would be.
The most prominent response, “Passkeys Are Not a Trap” by Scott Helme, made the front page of Hacker News too. He confidently claims that attestation does none of the things that The Hack claims it could do. He points out that widely used consumer password managers don’t support attestation.
When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its
AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
WebAuthn attestation could include all of those things. Android has, in fact, all the primitives already lying around and iOS does too. If an Android phone was the authenticator, it could include meaningful amounts of information about itself during attestation. And yes, the most popular implementations, synced passkey managers, don’t offer attestation at all, true. But that’s why The Hack argues it’s a trap. Adopt passkeys now while they are open and the restrictions come later.
In a Mastodon post, Ricky Mondello, who represents Apple in FIDO and W3C Working Groups related to WebAuthn, gives some more details about the history of attestation. They point out that the lack of attestation in implementations by popular platforms, browsers, and credential management apps is not an accident.
And trust me, websites and apps like banks repeatedly asked for attestation at the beginning of the industry’s passkey journey. The platforms, browsers, and credential management apps have held firm that the goal of passkeys is reducing phishing and not some kind of trusted computing scheme. (And I will note: over my dead body!)
The little that I know about Mondello gives me confidence that they mean what they say here. This is strengthened by the fact that neither Google nor Apple currently support attestation through their password managers. As picky as websites and apps may prefer to be, they realistically have no choice but to accept these implementations. Android and iOS devices are how most people will interact with passkeys after all.
Major consumer implementations also support moving passkeys between authenticators, including to open-source software like Bitwarden. It’s not a perfect “move your key from anywhere to anywhere,” but that is the direction we are headed in. Furthermore, WebAuthn doesn’t currently offer an easy path to pull the rug. Authenticator attestation can exist during key creation, but not during authentication. The authentication message doesn’t even include information about the authenticator meaning it’s not possible to detect that a key has been moved from one authenticator to another. You can see the full message format here: W3C WebAuthn Level 3, 5.2.2. Web Authentication Assertion 1.
That all sounds well and good, but passkeys being a trap is not exactly a far-fetched conspiracy theory either. If you browse the WebAuthn spec you will notice quickly that it takes a slightly different tone than Mondello did in their post:
Authenticators SHOULD also provide some form of attestation, if possible.
The Relying Party can optionally enforce requirements on authenticators’ security properties by inspecting the attestation statements returned from the authenticators.
And here is WebAuthn editor Tim Cappalli telling the maintainers of KeePassXC that he is reconsidering his opposition to attestation as a way to block authenticators because of implementations like theirs:
I’ve already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
That’s less reassuring. Though, of course, the spec can be as adamant about attestation as it wants to be. If the most popular authenticators don’t implement it, there isn’t much websites and apps can do.
That hasn’t stopped them from trying of course. Here is a Bitwarden user complaining that Swiss Post doesn’t allow authenticator providers outside of Google/Apple/Microsoft. Even without attestation, authenticators send an identifier, an AAGUID, and there is nothing stopping someone from being picky about which identifiers to accept. There is also nothing stopping an authenticator from lying about its AAGUID — the spec even recognizes this. Well, nothing besides attestation.
That seems to be the crux of the issue. What we are relying on isn’t a spec that explicitly prevents the abuse of users, it’s popular authenticators that are holding back those capabilities. I think it’s hard to blame someone for thinking that this arrangement looks rather trap-shaped.
For intelligence agencies, and for corporations like Microsoft, Google, Apple, Facebook, Amazon – giving you convenience and security is likely not their primary goal. I think they have an entirely ulterior motive. They can use passkeys to prevent you from running unapproved software.
Remote attestation can allow them to verify that your device is not capable of, say, sending and receiving encrypted messages, or running a competitor’s app, or using social media without verifying your ID.
The Hack does conjure up a conspiracy theory for us. Yes, remote attestation can provide evidence that a device is running an approved OS, and an approved OS could restrict access to those apps. But that has been possible for years and it hasn’t happened yet.
I am not saying it won’t, just that none of this requires passkeys. Apps already have access to attestation mechanisms — ask your bank about it. Neither Google nor Apple needs WebAuthn to restrict what software you can run on your devices. They’re quite capable of doing that without it.
As are governments. ID and age verification requirements already exist in some jurisdictions. Lawmakers just go the easy and obvious route and make the social media platforms ensure compliance. That works just fine with regular passwords.
I will go out on a limb and say that passkeys aren’t the result of Amazon wanting to restrict you from shopping elsewhere. Passkeys could make it easier for websites to demand attestation, and that’s worth worrying about. But I don’t think anyone is building a trap here; you don’t need to trap an animal that’s already in a cage. Perhaps that’s worth worrying about too.
-
authenticator data If you actually clicked on the link to read a W3C spec — good on you first of all — you might notice that one of the fields on the assertion is
authenticatorData, which itself includes the fieldattestedCredentialData. The standard explicitly says “For assertion signatures, the AT flag MUST NOT be set and theattestedCredentialDataMUST NOT be included.” ↩︎