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].
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.
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.
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.
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?
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.
> 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.
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).
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|8 months ago
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 [2] https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn... [3] https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn...
diggernet|8 months ago
jiveturkey|8 months ago
> 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|8 months ago
rlpb|8 months ago
Didn't we already know this?
didntcheck|8 months ago
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?
nullpt_rs|8 months ago
vmfunc|8 months ago
geoctl|8 months ago
jiveturkey|8 months ago
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.
palata|8 months ago
dufrfjjt|8 months ago
dufrfjjt|8 months ago
darkhorn|8 months ago
jeroenhd|8 months ago
arnarbi|8 months ago
WorldMaker|8 months ago
eidorb|8 months ago
webauthn in software https://github.com/bodik/soft-webauthn
Unofficial bank API client using software passkey: https://github.com/eidorb/ubank
curtisszmania|8 months ago
[deleted]