13 ms·

Breaking WebAuthn, FIDO2, and Forging Passkeys

61 points by vmfunc 1y ago

darkhorn 1y ago
What is passkey? I refuse anything that is not standardized? Aren't WebAuth or/and FIDO2 enough?
- jeroenhd 1y ago
  Passkey is what programs aimed at people without favorite Linux distros call WebAuthn+FIDO2(+CTAP2+the rest of the stack you've probably already heard of).
- arnarbi 1y ago
  It’s the same thing: https://fidoalliance.org/passkeys/ https://fidoalliance.org/passkeys/
- WorldMaker 1y ago
  Passkey is a "brand name" for consumers of common workflows under existing WebAuthn+FIDO2 standards. It needed a consumer-oriented brand name because FIDO2 sounds like someone was bad at naming their dog and WebAuthn looks like a cat walked on someone's keyboard. Passkey isn't that much better as a name, but it is better.
agl 1y ago
Setting a signature counter to constant zero is explicitly supported[1] and it's not a bug that it works. Google does not require the signature counter to increment; it's something else invalid about the response that's tripping it up. The security story for signature counters is subtle[2] and the vast (vast) majority of sites are correct not to require them. Using the Chrome virtual authenticator indeed works, and from the DevTools UI directly (three dots -> More Tools -> WebAuthn), no sockets required. It's not a vulnerability that it works. If it didn't, Apple, Google, and Microsoft would be effectively the only possible passkey providers. You can lock it down in enterprise environments if you need[3]. [1] https://www.w3.org/TR/webauthn-3/#sctn-sign-counter https://www.w3.org/TR/webauthn-3/#sctn-sign-counter [2] https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html#signature-counters https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn... [3] https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html#enterprise-attestation https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn...
- diggernet 1y ago
  Interesting. If the counter can be zero, does that mean passkeys can be non-resident keys? And which party gets to decide the counter value?
curtisszmania 1y ago
[dead]
palata 1y ago
Great and very interesting writeup! Not sure if that's more "Breaking" than "Deconstructing", but still it's very insightful.
eidorb 1y ago
See also: webauthn in software https://github.com/bodik/soft-webauthn https://github.com/bodik/soft-webauthn Unofficial bank API client using software passkey: https://github.com/eidorb/ubank https://github.com/eidorb/ubank
dufrfjjt 1y ago
hdtvfhftuudyggffygftxd9999999999999999999999999 Ydhggcgftdfrdtdrfyg6yuiggbgcghngdh9999999999976 Yfhtygfggjhjjj
dufrfjjt 1y ago
C999999999999999999999999999999999999999999c9ĉ
rlpb 1y ago
I'm not sure what this "breaks". Unless a site requires attestation and validates that attestation, a bad software FIDO2 implementation will leave users vulnerable should they choose to use one. Didn't we already know this?
- didntcheck 1y ago
  If anything I'm worried that corporate security people will hear of "attacks" like this and blindly add "must use attestation with passkeys" to their checklists, and desktop computing will end up in the same state as mobile, where you have to have an unmodified OS install from one of a handful of authorized fiefdoms to log into your bank. It's a long way off, due to the amount of old laptops with no TPM about, but a plausible future Edit: I may be misunderstanding the scope of attestation in a FIDO/Webauthn context. Is it a legitimate concern that it would lock out other OSes, or would you simply need a hardware key (or perhaps a TPM), but could run what you want above it?
  - mjg59 1y ago
    The attestation is purely the MFA token, not the OS
    - tialaramex 1y ago
      It is still almost always unwanted garbage though, which is why the specification says please don't. We know from the Web PKI how this goes. People who have no idea what they're doing copy-paste a "good" list in 2025, but in 2035 the fact a third of vendors on that "good" list are now known villains and another third went bankrupt doesn't change the problem that stuff on the list works and everything else doesn't, because it was mindlessly copy-pasted Narrowly, the vendor attestation could make sense if you're BigBank and you bought every employee (or maybe every customer, I wish) a FooCo security key, you can require FooCo security keys. If you're big enough you could have FooCo make you a custom model (maybe with your company logo) and attest every key is the custom model. I expect Yubico would sell you that product, if you were willing to commit to the volume. You get assurance of the exact hardware properties, and you retain the option to shop around by updating your software to trust different attestation. IMO not worth standardizing, but people really wanted this and better it exists but isn't used than it doesn't exist so they walk away.
geoctl 1y ago
Great effort. I honestly doubt that any B2C or even the vast majority of B2B relying parties do verification of attestation statements during registration which means the relying party never really knows whether the authenticator's public key is actually generated by a real security key, TPM, etc... or just generated by software. I guess FIDO MDS can currently act as a solution to some degree but it might possibly break passkeys legitimately generated by software such as password managers, not to mention that when it comes to TPMs for example, the process is messy and unpredictable. Many TPMs don't even send their own entire x5c because of size and storage limitations.
- jiveturkey 1y ago
  > I honestly doubt that any B2C or even the vast majority of B2B relying parties do verification of attestation statements It took Apple to implement passkeys, for FIDO auth to become as popular as it is today. Apple does not attest because they were lazy. So yes, AFAIK only a few finance sites require attestation. (For internal auth, many IdPs can optionally require attestation, from limited signing authorities. Through federation this attested auth can be used elsewhere but I don't know of any mechanism for asserting that to any relying party.) Yes, lazy. They knew that passkeys needed to be portable to other devices. Otherwise backups (well, recovery) would be impossibly difficult, as is the case with U2F today. The way the keys are passed around by Apple does not expose them, but they didn't bother to build an ecosystem where an attestation could also be portable (think: Security World). Why bother (it's fairly hard) when you can just not attest, and you have the weight to force everyone to accept it anyway? As long as you are within the Apple ecosystem, using a legitimate hardware-generated passkey, the attestation doesn't matter anyway. So screw everyone else. FIDO should have rejected this approach but from the very beginning they were captured by the largest corporate interests. Now to get back to your doubt, if a registration is attested, I would be surprised if it is ignored.
  - cyberax 1y ago
    > Apple does not attest because they were lazy. It's not "lazy", it's "impossible". If you want to have synced keys, you need to have them unencrypted. Otherwise, you need to be able to establish secure links between various secure hardware storage devices. Apple can do that within their infrastructure, perhaps. But there's just no way to do that across multiple vendors. > FIDO should have rejected this approach but from the very beginning they were captured by the largest corporate interests. Why? Passkeys are a perfect replacement for login/password pairs. Their implementations can also be secured as much as possible by each vendor. And you _can_ require attestation in your WebAuthn implementation, if you think that your data is too precious.
jiveturkey 1y ago
Not understanding forgery. What is being forged? You have the key material. > I wanted cryptographic proof the signature is correct before trying to forge my own. But you aren't forging anything? You are producing a signature from your own key material? I could be missing something important, certainly. But wouldn't this be earth shattering if you can forge a p256 signature? Apologies if I'm just not getting it. > Today we will: ... Explore [...] cloning credentials. Perhaps I didn't read it well enough yet, but I don't see any cloning going on here. Lastly, a lot of work was done reverse engineering that could also have happened just from reading docs. I suppose from the POV of implementing a software passkey, it's useful to have written the tracing tools for help validating your own implementation. But it's presented as if you were uncovering a secret part of the protocol. > Do Big Sites Care? A more important question is: should they? Left as an exercise. > reverse-engineering CTAP2 at the byte level, Is it reverse-engineering? Feels more like decoding. Forgive me again if I didn't understand.
- kd5bjo 1y ago
  It’s an attack that lets the malicious actor hijack the passkey registration flow to insert a key that they know, so that they can later log in as the victim.
  - warkdarrior 1y ago
    If the computer where registration happens is not trusted, no authentication protocol will help. Compare this attack ("malicious computer substitutes passkey at registration time") with a password one ("malicious computer substitutes password at registration time").
    - lxgr 1y ago
      But unlike a compromised password, a compromised passkey can be detected much more easily, since the "real" key will end up not working, unless the attacker also adds it to the victim's account.
      - 1y ago

61 points by vmfunc 1y ago

darkhorn 1y ago

What is passkey? I refuse anything that is not standardized? Aren't WebAuth or/and FIDO2 enough?

jeroenhd 1y ago
Passkey is what programs aimed at people without favorite Linux distros call WebAuthn+FIDO2(+CTAP2+the rest of the stack you've probably already heard of).
arnarbi 1y ago
It’s the same thing: https://fidoalliance.org/passkeys/ https://fidoalliance.org/passkeys/
WorldMaker 1y ago
Passkey is a "brand name" for consumers of common workflows under existing WebAuthn+FIDO2 standards. It needed a consumer-oriented brand name because FIDO2 sounds like someone was bad at naming their dog and WebAuthn looks like a cat walked on someone's keyboard. Passkey isn't that much better as a name, but it is better.

agl 1y ago

Setting a signature counter to constant zero is explicitly supported[1] and it's not a bug that it works. Google does not require the signature counter to increment; it's something else invalid about the response that's tripping it up. The security story for signature counters is subtle[2] and the vast (vast) majority of sites are correct not to require them. Using the Chrome virtual authenticator indeed works, and from the DevTools UI directly (three dots -> More Tools -> WebAuthn), no sockets required. It's not a vulnerability that it works. If it didn't, Apple, Google, and Microsoft would be effectively the only possible passkey providers. You can lock it down in enterprise environments if you need[3]. [1] https://www.w3.org/TR/webauthn-3/#sctn-sign-counter https://www.w3.org/TR/webauthn-3/#sctn-sign-counter [2] https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html#signature-counters https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn... [3] https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html#enterprise-attestation https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn...

diggernet 1y ago
Interesting. If the counter can be zero, does that mean passkeys can be non-resident keys? And which party gets to decide the counter value?

curtisszmania 1y ago

[dead]

palata 1y ago

Great and very interesting writeup! Not sure if that's more "Breaking" than "Deconstructing", but still it's very insightful.

eidorb 1y ago

See also: webauthn in software https://github.com/bodik/soft-webauthn https://github.com/bodik/soft-webauthn Unofficial bank API client using software passkey: https://github.com/eidorb/ubank https://github.com/eidorb/ubank

dufrfjjt 1y ago

hdtvfhftuudyggffygftxd9999999999999999999999999 Ydhggcgftdfrdtdrfyg6yuiggbgcghngdh9999999999976 Yfhtygfggjhjjj

dufrfjjt 1y ago

C999999999999999999999999999999999999999999c9ĉ

rlpb 1y ago

I'm not sure what this "breaks". Unless a site requires attestation and validates that attestation, a bad software FIDO2 implementation will leave users vulnerable should they choose to use one. Didn't we already know this?

didntcheck 1y ago
If anything I'm worried that corporate security people will hear of "attacks" like this and blindly add "must use attestation with passkeys" to their checklists, and desktop computing will end up in the same state as mobile, where you have to have an unmodified OS install from one of a handful of authorized fiefdoms to log into your bank. It's a long way off, due to the amount of old laptops with no TPM about, but a plausible future Edit: I may be misunderstanding the scope of attestation in a FIDO/Webauthn context. Is it a legitimate concern that it would lock out other OSes, or would you simply need a hardware key (or perhaps a TPM), but could run what you want above it?
- mjg59 1y ago
  The attestation is purely the MFA token, not the OS
  - tialaramex 1y ago
    It is still almost always unwanted garbage though, which is why the specification says please don't. We know from the Web PKI how this goes. People who have no idea what they're doing copy-paste a "good" list in 2025, but in 2035 the fact a third of vendors on that "good" list are now known villains and another third went bankrupt doesn't change the problem that stuff on the list works and everything else doesn't, because it was mindlessly copy-pasted Narrowly, the vendor attestation could make sense if you're BigBank and you bought every employee (or maybe every customer, I wish) a FooCo security key, you can require FooCo security keys. If you're big enough you could have FooCo make you a custom model (maybe with your company logo) and attest every key is the custom model. I expect Yubico would sell you that product, if you were willing to commit to the volume. You get assurance of the exact hardware properties, and you retain the option to shop around by updating your software to trust different attestation. IMO not worth standardizing, but people really wanted this and better it exists but isn't used than it doesn't exist so they walk away.

geoctl 1y ago

Great effort. I honestly doubt that any B2C or even the vast majority of B2B relying parties do verification of attestation statements during registration which means the relying party never really knows whether the authenticator's public key is actually generated by a real security key, TPM, etc... or just generated by software. I guess FIDO MDS can currently act as a solution to some degree but it might possibly break passkeys legitimately generated by software such as password managers, not to mention that when it comes to TPMs for example, the process is messy and unpredictable. Many TPMs don't even send their own entire x5c because of size and storage limitations.

jiveturkey 1y ago
> I honestly doubt that any B2C or even the vast majority of B2B relying parties do verification of attestation statements It took Apple to implement passkeys, for FIDO auth to become as popular as it is today. Apple does not attest because they were lazy. So yes, AFAIK only a few finance sites require attestation. (For internal auth, many IdPs can optionally require attestation, from limited signing authorities. Through federation this attested auth can be used elsewhere but I don't know of any mechanism for asserting that to any relying party.) Yes, lazy. They knew that passkeys needed to be portable to other devices. Otherwise backups (well, recovery) would be impossibly difficult, as is the case with U2F today. The way the keys are passed around by Apple does not expose them, but they didn't bother to build an ecosystem where an attestation could also be portable (think: Security World). Why bother (it's fairly hard) when you can just not attest, and you have the weight to force everyone to accept it anyway? As long as you are within the Apple ecosystem, using a legitimate hardware-generated passkey, the attestation doesn't matter anyway. So screw everyone else. FIDO should have rejected this approach but from the very beginning they were captured by the largest corporate interests. Now to get back to your doubt, if a registration is attested, I would be surprised if it is ignored.
- cyberax 1y ago
  > Apple does not attest because they were lazy. It's not "lazy", it's "impossible". If you want to have synced keys, you need to have them unencrypted. Otherwise, you need to be able to establish secure links between various secure hardware storage devices. Apple can do that within their infrastructure, perhaps. But there's just no way to do that across multiple vendors. > FIDO should have rejected this approach but from the very beginning they were captured by the largest corporate interests. Why? Passkeys are a perfect replacement for login/password pairs. Their implementations can also be secured as much as possible by each vendor. And you _can_ require attestation in your WebAuthn implementation, if you think that your data is too precious.

jiveturkey 1y ago

Not understanding forgery. What is being forged? You have the key material. > I wanted cryptographic proof the signature is correct before trying to forge my own. But you aren't forging anything? You are producing a signature from your own key material? I could be missing something important, certainly. But wouldn't this be earth shattering if you can forge a p256 signature? Apologies if I'm just not getting it. > Today we will: ... Explore [...] cloning credentials. Perhaps I didn't read it well enough yet, but I don't see any cloning going on here. Lastly, a lot of work was done reverse engineering that could also have happened just from reading docs. I suppose from the POV of implementing a software passkey, it's useful to have written the tracing tools for help validating your own implementation. But it's presented as if you were uncovering a secret part of the protocol. > Do Big Sites Care? A more important question is: should they? Left as an exercise. > reverse-engineering CTAP2 at the byte level, Is it reverse-engineering? Feels more like decoding. Forgive me again if I didn't understand.

kd5bjo 1y ago
It’s an attack that lets the malicious actor hijack the passkey registration flow to insert a key that they know, so that they can later log in as the victim.
- warkdarrior 1y ago
  If the computer where registration happens is not trusted, no authentication protocol will help. Compare this attack ("malicious computer substitutes passkey at registration time") with a password one ("malicious computer substitutes password at registration time").
  - lxgr 1y ago
    But unlike a compromised password, a compromised passkey can be detected much more easily, since the "real" key will end up not working, unless the attacker also adds it to the victim's account.
    - 1y ago