Breaking WebAuthn, FIDO2, and Forging Passkeys(nullpt.rs)
nullpt.rs
Breaking WebAuthn, FIDO2, and Forging Passkeys
https://www.nullpt.rs/forging-passkeys
51 comments
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.
> 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.
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").
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.
Then it should be very obvious if the site displays the user's registered passkeys.
That should be very noticeable to the victim though, right?
Their own key would not work (unless the attacker persistently MITMs them and swaps their own credential in for every subsequent authentication) or they'd see multiple credentials being present in their account.
It's also a good idea to send out an email for every new credential added.
Their own key would not work (unless the attacker persistently MITMs them and swaps their own credential in for every subsequent authentication) or they'd see multiple credentials being present in their account.
It's also a good idea to send out an email for every new credential added.
> Chrome needs to be started with remote debugging
Pretty confident that is out of scope for any reasonable threat model.
Pretty confident that is out of scope for any reasonable threat model.
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?
Didn't we already know this?
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?
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?
> add "must use attestation with passkeys" to their checklists
We already do. Mostly from the compliance side: I can't call passkeys "phishing-resistant" unless I can lock them down into unexportable passkey providers only. Some more details from a previous comment of mine:
From a corporate compliance perspective, I need to ensure that employee keys are stored in a FIPS-compliant TPM and unexportable. Key loss is not an issue because we have, ya know, an IT department. The only way I can ensure this happens is by whitelisting AAGUIDs and enforcing attestation.
With these factors I can also get out of the MFA hellhole (because I can prove that whitelisted vendor X already performs MFA on-device without me having to manage it: for example, WHFB requires something you have (keys in your TPM) and either something you are (face scan / fingerprint) or something you know (PIN), without me having to store/verify any of those factors or otherwise manage them). Same goes for passkeys stored in MS Authenticator on iOS/Android.
We already do. Mostly from the compliance side: I can't call passkeys "phishing-resistant" unless I can lock them down into unexportable passkey providers only. Some more details from a previous comment of mine:
From a corporate compliance perspective, I need to ensure that employee keys are stored in a FIPS-compliant TPM and unexportable. Key loss is not an issue because we have, ya know, an IT department. The only way I can ensure this happens is by whitelisting AAGUIDs and enforcing attestation.
With these factors I can also get out of the MFA hellhole (because I can prove that whitelisted vendor X already performs MFA on-device without me having to manage it: for example, WHFB requires something you have (keys in your TPM) and either something you are (face scan / fingerprint) or something you know (PIN), without me having to store/verify any of those factors or otherwise manage them). Same goes for passkeys stored in MS Authenticator on iOS/Android.
>I can't call passkeys "phishing-resistant" unless I can lock them down into unexportable passkey providers only
I don't think this is accurate. As far as I know, no credential managers (except for maybe KeePassX) allow export of passkeys, and will instead only allow for secure transfer via the new Credential Exchange Protocol.
I don't think this is accurate. As far as I know, no credential managers (except for maybe KeePassX) allow export of passkeys, and will instead only allow for secure transfer via the new Credential Exchange Protocol.
> secure transfer via the new Credential Exchange Protocol
If it's "transferable", it's not phishing-resistant (ie it's possible for a user to get bamboozled into transferring their keys to a bad actor), right? Regardless of mechanism.
You might've missed the "FIPS" part as well. This requirement effectively means the keys (or the keys to decrypt the keys) must be stored in a tamper-resistant hardware crypto device (read: your TPM) and basically no credential managers (apart from the first-party ones we have whitelisted) use the TPM for storing your keys.
If it's "transferable", it's not phishing-resistant (ie it's possible for a user to get bamboozled into transferring their keys to a bad actor), right? Regardless of mechanism.
You might've missed the "FIPS" part as well. This requirement effectively means the keys (or the keys to decrypt the keys) must be stored in a tamper-resistant hardware crypto device (read: your TPM) and basically no credential managers (apart from the first-party ones we have whitelisted) use the TPM for storing your keys.
> It's a long way off, due to the amount of old laptops with no TPM about, but a plausible future
TPMs can't create hardware-attested passkeys, at least they couldn't do that with the TPM 2.0 spec.
And you can just use a USB hardware token to get attested keys. Or you can use WebAuthn over Bluetooth to your phone, essentially using your phone's secure enclave (or its equivalent) as the key source.
Being able to require attested passkeys is a _good_ thing.
TPMs can't create hardware-attested passkeys, at least they couldn't do that with the TPM 2.0 spec.
And you can just use a USB hardware token to get attested keys. Or you can use WebAuthn over Bluetooth to your phone, essentially using your phone's secure enclave (or its equivalent) as the key source.
Being able to require attested passkeys is a _good_ thing.
Except it means backing up or moving your credentials is somewhere between a pain and infeasible, and you're requiring people to go buy another device for little to no real security benefit. Every browser already generates strong random passwords that are tied to specific sites. They've done so for many years. Passkey attestation in a non-managed-org context is trying to solve a problem that's way past the point of diminishing returns while making things more fragile for users. You also can't really do attestation without having a blessed set of vendors (otherwise a software implementation could do it), so lockin is required.
> Except it means backing up or moving your credentials is somewhere between a pain and infeasible
That's the point.
> and you're requiring people to go buy another device for little to no real security benefit.
No. The benefit is clearly there: hardware-originated keys can not be stolen under any normal circumstances. Meanwhile, synced passkeys are just fancy login/password pairs, so they can be exfiltrated by an attacker. E.g. by scanning the RAM of the passkey manager.
Of course, the operating system can try to add additional barriers, but the underlying keys must at some point be in clear text form.
That's the point.
> and you're requiring people to go buy another device for little to no real security benefit.
No. The benefit is clearly there: hardware-originated keys can not be stolen under any normal circumstances. Meanwhile, synced passkeys are just fancy login/password pairs, so they can be exfiltrated by an attacker. E.g. by scanning the RAM of the passkey manager.
Of course, the operating system can try to add additional barriers, but the underlying keys must at some point be in clear text form.
Right, that makes such a system unusable for normal people, so it is not a good thing to force it upon them. The benefit is not clearly there because anything that can manipulate local memory can also just use the key directly, or if there's some kind of physical button press required, wait for the user to log in and then do whatever they want with the session cookie or alter page contents or do anything else it wants. If the token doesn't display what it's authorizing (e.g. a yubikey), you could also watch for any usage, block that request to the device, and instead auth against their bank. If you need multiple button presses (e.g. they need to press again to confirm a transfer), say there was an error and ask them to try again.
Normal people are however not concerned with these Mission Impossible scenarios, and random passwords are good enough while being easy to use without an IT department to fix when it goes wrong. A password manager (which every browser has built in) already associates passwords to domains for phishing resistance. Users already should never need to enter a password manually unless the site did something stupid to try to block the password manager from working.
Normal people are however not concerned with these Mission Impossible scenarios, and random passwords are good enough while being easy to use without an IT department to fix when it goes wrong. A password manager (which every browser has built in) already associates passwords to domains for phishing resistance. Users already should never need to enter a password manually unless the site did something stupid to try to block the password manager from working.
> Right, that makes such a system unusable for normal people, so it is not a good thing to force it upon them.
Whut? Passkeys work perfectly fine for "normal people".
> The benefit is not clearly there because anything that can manipulate local memory can also just use the key directly
Correct. But it does require fairly high level of system access. Hardware-bound keys also allow full hardware-attested authentication.
> Normal people are however not concerned with these Mission Impossible scenarios, and random passwords are good enough while being easy to use without an IT department to fix when it goes wrong.
If you're using truly random passwords, then you're using a password manager. And if you're using a password manager, then why not just use passkeys?
All the popular password managers support them: BitWarden, 1Pass, iCloud Keychain, even LastPass.
Whut? Passkeys work perfectly fine for "normal people".
> The benefit is not clearly there because anything that can manipulate local memory can also just use the key directly
Correct. But it does require fairly high level of system access. Hardware-bound keys also allow full hardware-attested authentication.
> Normal people are however not concerned with these Mission Impossible scenarios, and random passwords are good enough while being easy to use without an IT department to fix when it goes wrong.
If you're using truly random passwords, then you're using a password manager. And if you're using a password manager, then why not just use passkeys?
All the popular password managers support them: BitWarden, 1Pass, iCloud Keychain, even LastPass.
Passkeys don't offer anything above random passwords, and hardware attested passkeys obviously cannot work with a software password manager, which is the point.
Also like I keep saying, every browser already has a password manager. You don't need an external one. Notably though, Firefox's password manager doesn't support software passkeys, so they are completely unusable for me, for example. I'm certainly not going to sign up for some SaaS so I can use a worse version of passwords.
Also like I keep saying, every browser already has a password manager. You don't need an external one. Notably though, Firefox's password manager doesn't support software passkeys, so they are completely unusable for me, for example. I'm certainly not going to sign up for some SaaS so I can use a worse version of passwords.
> synced passkeys are just fancy login/password pairs, so they can be exfiltrated by an attacker. E.g. by scanning the RAM of the passkey manager.
That’s an overly reductionist view.
Lots of password compromises still happen due to credential reuse across services, server-side compromises paired with brute-force-able passwords, and phishing/MITM attacks, and software-based WebAuthN credentials prevent all of these.
That’s an overly reductionist view.
Lots of password compromises still happen due to credential reuse across services, server-side compromises paired with brute-force-able passwords, and phishing/MITM attacks, and software-based WebAuthN credentials prevent all of these.
> Or you can use WebAuthn over Bluetooth to your phone, essentially using your phone's secure enclave (or its equivalent) as the key source.
As far as I remember, attestation is fully gone on iOS ("Passkeys" or otherwise), and mostly gone on Android too.
As far as I remember, attestation is fully gone on iOS ("Passkeys" or otherwise), and mostly gone on Android too.
The spec tells websites to please not do validation on specific hardware. You can do a light form of remote attestation, but you'll have to convince the user to use passkeys only and not some kind of username+password backup, which is still a tough sell.
If you want remote attestation, Safari already has it, but I'm not sure if their attempt at standardising is going anywhere. It's been a while since the draft got updated or mentioned anywhere.
If you want remote attestation, Safari already has it, but I'm not sure if their attempt at standardising is going anywhere. It's been a while since the draft got updated or mentioned anywhere.
> If you want remote attestation, Safari already has it
No, Safari/Apple gave up on remote attestation when they introduced passkeys, except for MDM devices where the MDM profile can allow attestation for RP domains on an opt-in basis.
No, Safari/Apple gave up on remote attestation when they introduced passkeys, except for MDM devices where the MDM profile can allow attestation for RP domains on an opt-in basis.
>except for MDM devices where the MDM profile can allow attestation for RP domains on an opt-in basis.
And even then, the attestation you get in that scenario is just an attestation that the passkey was created on a managed device. It is not a hardware/device attestation.
And even then, the attestation you get in that scenario is just an attestation that the passkey was created on a managed device. It is not a hardware/device attestation.
But only Apple devices can be managed, and presumably that’s in turn attested to by Apple cryptographic keys in hardware?
If this "attack" convinces security people of anything that just thinking through the FIDO/WebAuthN specs and threat model didn't already, I'd be concerned about the general quality of their work.
The attestation is purely the MFA token, not the OS
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.
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.
"breaking" might've been a strong verb here. updated post title to better reflect the intentions of the post :)
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.
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.
> 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.
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.
> But there's just no way to do that across multiple vendors.
Sure there is!
Since some superior body (FIDO) needs to declare which are the valid (or "most valid") attestation certs, not unlike the web PKI, and attestation (at higher levels) "demands" that keymat be held strictly secure by the attesting device, the CXP can be modified such that if the keymat passes between two attesting (and "arms length") authenticators, both at the same FIDO MDS level (or receiver greater), a bit is set in the exchange which tells the new/receiving authenticator to include ED in the attestation statement. That ED will indicate that the keymat passed from the original authenticator to the new authenticator, securely ie without ever being wrapped in a way that the user themselves (thus malware) had access to wrapping keys. This ED could include an original attestation as well, or not. Probably not since it wouldn't be against a nonce. Anyway, the RP can see this ED and then accept the new attestation even against a different one at registration time.
Of course this requires use of CXP and not some proprietary (frictionless) self-sync mechanism. Making that CXP "friendly" is a bunch of work, the actual hard part IMO. There's a lot more I could go on about but everyone will have lost interest by now.
Apple doesn't care about portability, the opposite in fact. Claiming that as the reason is quite a stretch. But I'm not speaking to that, just to the possibility (very much so) of such an interoperable sync between attesting but disparate authenticators.
Yes, an RP can require attestation, and yes an RP can require that attestations be FIDO MDS certified, anyway. What Apple has done is made their own job easier, out of laziness I say, because without attestation, within their own ecosystem they now don't need to create "Security Worlds" where they can attest (with same attestation cert) across synced devices. This benefits Apple, and actually Apple users, since users' keys are safe/secure if using Apple authenticators, whether attested or not, and whether RP cares or not! But the weight of Apple means that relying parties have to give up on attestation since Apple doesn't do it.
Using attestation wouldn't preclude software authenticators such as ye olde password managers, so it wouldn't force a lockout of small tech that other sibling posts are claiming are Apple's virtuous motivations. As you are correctly noting, RPs can require attestation -- well, RPs can also not require attestation if your data is not all that precious. Just as some large U2F RPs didn't require attestation. (UX, not attestation, was more the issue for U2F.) FIDO can still make a strongly worded recommendation to keep attestation optional, but eg let users know they are using an "L1" not an "L2" authenticator. Apple could have pushed to make that happen, instead of pushing non-attestation. So I still submit they took the easy/lazy way out.
> perfect replacement
hardly. at least not so far as has been realized today. (perfect is too strong a word)
Sure there is!
Since some superior body (FIDO) needs to declare which are the valid (or "most valid") attestation certs, not unlike the web PKI, and attestation (at higher levels) "demands" that keymat be held strictly secure by the attesting device, the CXP can be modified such that if the keymat passes between two attesting (and "arms length") authenticators, both at the same FIDO MDS level (or receiver greater), a bit is set in the exchange which tells the new/receiving authenticator to include ED in the attestation statement. That ED will indicate that the keymat passed from the original authenticator to the new authenticator, securely ie without ever being wrapped in a way that the user themselves (thus malware) had access to wrapping keys. This ED could include an original attestation as well, or not. Probably not since it wouldn't be against a nonce. Anyway, the RP can see this ED and then accept the new attestation even against a different one at registration time.
Of course this requires use of CXP and not some proprietary (frictionless) self-sync mechanism. Making that CXP "friendly" is a bunch of work, the actual hard part IMO. There's a lot more I could go on about but everyone will have lost interest by now.
Apple doesn't care about portability, the opposite in fact. Claiming that as the reason is quite a stretch. But I'm not speaking to that, just to the possibility (very much so) of such an interoperable sync between attesting but disparate authenticators.
Yes, an RP can require attestation, and yes an RP can require that attestations be FIDO MDS certified, anyway. What Apple has done is made their own job easier, out of laziness I say, because without attestation, within their own ecosystem they now don't need to create "Security Worlds" where they can attest (with same attestation cert) across synced devices. This benefits Apple, and actually Apple users, since users' keys are safe/secure if using Apple authenticators, whether attested or not, and whether RP cares or not! But the weight of Apple means that relying parties have to give up on attestation since Apple doesn't do it.
Using attestation wouldn't preclude software authenticators such as ye olde password managers, so it wouldn't force a lockout of small tech that other sibling posts are claiming are Apple's virtuous motivations. As you are correctly noting, RPs can require attestation -- well, RPs can also not require attestation if your data is not all that precious. Just as some large U2F RPs didn't require attestation. (UX, not attestation, was more the issue for U2F.) FIDO can still make a strongly worded recommendation to keep attestation optional, but eg let users know they are using an "L1" not an "L2" authenticator. Apple could have pushed to make that happen, instead of pushing non-attestation. So I still submit they took the easy/lazy way out.
> perfect replacement
hardly. at least not so far as has been realized today. (perfect is too strong a word)
> Apple does not attest because they were lazy.
Apple has made clear statements in places such as WWDC talks that they believe attestations are bad for consumer privacy and consumer choice (migrating between Passkey providers, using Password Managers of their choice). They support attestations in very specific enterprise scenarios, so they didn't lazily ignore the work altogether, they just locked it behind a security fence (MDM environments).
Apple has put in extra work to champion other (optional) parts of the spec trying to provide some of what attestation was built to do, but in more privacy-focused/privacy-preserving ways.
> FIDO should have rejected this approach but from the very beginning they were captured by the largest corporate interests.
From the standpoint of consumer Passkey privacy it certainly feels a lot more that attestations were the capture by the largest corporate interests (both Google and Microsoft championed for them as core parts of the specs), and Apple's lone dissent of the big three is the one thing stopping FIDO from having made attestations required rather than optional.
Apple has made clear statements in places such as WWDC talks that they believe attestations are bad for consumer privacy and consumer choice (migrating between Passkey providers, using Password Managers of their choice). They support attestations in very specific enterprise scenarios, so they didn't lazily ignore the work altogether, they just locked it behind a security fence (MDM environments).
Apple has put in extra work to champion other (optional) parts of the spec trying to provide some of what attestation was built to do, but in more privacy-focused/privacy-preserving ways.
> FIDO should have rejected this approach but from the very beginning they were captured by the largest corporate interests.
From the standpoint of consumer Passkey privacy it certainly feels a lot more that attestations were the capture by the largest corporate interests (both Google and Microsoft championed for them as core parts of the specs), and Apple's lone dissent of the big three is the one thing stopping FIDO from having made attestations required rather than optional.
> Apple does not attest because they were lazy.
Apple used to support attestation, so while their decision to discontinue it for passkeys might have many possible motivations, laziness is the least likely in my view.
My personal take is that they've done the world a favor by removing it. If they hadn't, Google would have probably followed suit (possibly even doing it in software using some handwavy "Safety Net" arguments), and 1Password, Bitwarden, Keepass etc. would be locked out of more and more sites.
Apple used to support attestation, so while their decision to discontinue it for passkeys might have many possible motivations, laziness is the least likely in my view.
My personal take is that they've done the world a favor by removing it. If they hadn't, Google would have probably followed suit (possibly even doing it in software using some handwavy "Safety Net" arguments), and 1Password, Bitwarden, Keepass etc. would be locked out of more and more sites.
I believe there is more to the problem than just laziness from the relying party side. The problem is what do you verify against? It's not as easy as in, for example, TLS handshake where browsers/HTTP clients have well-defined root CAs to verify the provided server cert against. It's easier for security keys (e.g. yubikeys) where you can just use the FIDO MDS service but there are many other uncovered use cases such as TPMs and browser/password manager generated passkeys. The current WebAuthn/passkey registration process is practically TOFU at this point which is funny since this by itself negates the entire rationale behind hardware-based phishing resistant authenticators. And since you mentioned Apple, as far as I know and I could be wrong for their newer products, it doesn't even provide real attestation statements to begin with like in Android or Windows Hello devices. The entire standard is currently practically based on TOFU "trust me bro, I am a hardware-based generated key lol"-tier registration process.
> The current WebAuthn/passkey registration process is practically TOFU at this point which is funny since this by itself negates the entire rationale behind hardware-based phishing resistant authenticators.
This is not an accurate description of the point of Fido phishing resistance. It isn't to make a bank feel happy the user has a hardware key unless you choose attestation. It is to make the user happy that if they click the key they know is hardware on the wrong site then that site can't MITM a site they intend to authenticate to.
(Stopping users from reusing the protocol for security between passwords and real hardware keys is basically just forcing the DRM for SaaS aspect of attestation on people because you can. If you aren't the kind of institution that issued real tokens to account holders then it is none of your business.)
This is not an accurate description of the point of Fido phishing resistance. It isn't to make a bank feel happy the user has a hardware key unless you choose attestation. It is to make the user happy that if they click the key they know is hardware on the wrong site then that site can't MITM a site they intend to authenticate to.
(Stopping users from reusing the protocol for security between passwords and real hardware keys is basically just forcing the DRM for SaaS aspect of attestation on people because you can. If you aren't the kind of institution that issued real tokens to account holders then it is none of your business.)
Great and very interesting writeup! Not sure if that's more "Breaking" than "Deconstructing", but still it's very insightful.
C999999999999999999999999999999999999999999c9ĉ
hdtvfhftuudyggffygftxd9999999999999999999999999
Ydhggcgftdfrdtdrfyg6yuiggbgcghngdh9999999999976
Yfhtygfggjhjjj
What is passkey? I refuse anything that is not standardized? Aren't WebAuth or/and FIDO2 enough?
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).
It’s the same thing: https://fidoalliance.org/passkeys/
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.
See also:
webauthn in software https://github.com/bodik/soft-webauthn
Unofficial bank API client using software passkey: https://github.com/eidorb/ubank
webauthn in software https://github.com/bodik/soft-webauthn
Unofficial bank API client using software passkey: https://github.com/eidorb/ubank
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...