[HN Gopher] Breaking WebAuthn, FIDO2, and Forging Passkeys
___________________________________________________________________
Breaking WebAuthn, FIDO2, and Forging Passkeys
Author : vmfunc
Score : 54 points
Date : 2025-06-20 16:55 UTC (4 days ago)
(HTM) web link (www.nullpt.rs)
(TXT) w3m dump (www.nullpt.rs)
| rlpb wrote:
| 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?
| vmfunc wrote:
| see https://x.com/vmfunc/status/1936120644087001297
| ThePowerOfFuet wrote:
| https://xcancel.com/vmfunc/status/1936120644087001297
| nullpt_rs wrote:
| "breaking" might've been a strong verb here. updated post title
| to better reflect the intentions of the post :)
| didntcheck wrote:
| 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 wrote:
| The attestation is purely the MFA token, not the OS
| tialaramex wrote:
| 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.
| jeroenhd wrote:
| 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.
| lxgr wrote:
| > 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.
| cyberax wrote:
| > 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.
| ndriscoll wrote:
| 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.
| cyberax wrote:
| > 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.
| ndriscoll wrote:
| 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.
| lxgr wrote:
| > 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.
| lxgr wrote:
| > 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.
| cyberax wrote:
| It's still there. You can request an attested credential,
| it just won't be synced.
| lxgr wrote:
| Not on iOS, except for devices with MDM profiles
| explicitly opting a given RP domain in.
|
| It's unfortunately not possible to even request a non-
| synced credential anymore for non-MDM-approved websites.
| parliament32 wrote:
| > 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.
| lxgr wrote:
| 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.
| geoctl wrote:
| 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 wrote:
| > 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.
| geoctl wrote:
| 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.
| fredfish wrote:
| > 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.)
| cyberax wrote:
| > 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.
| lxgr wrote:
| > 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.
| WorldMaker wrote:
| > 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.
| jiveturkey wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| lxgr wrote:
| 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.
| jiveturkey wrote:
| > Chrome needs to be started with remote debugging
|
| Pretty confident that is out of scope for any reasonable
| threat model.
| darkhorn wrote:
| What is passkey? I refuse anything that is not standardized?
| Aren't WebAuth or/and FIDO2 enough?
| jeroenhd wrote:
| 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 wrote:
| It's the same thing: https://fidoalliance.org/passkeys/
| WorldMaker wrote:
| 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 wrote:
| 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 [2]
| https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn...
| [3]
| https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn...
| palata wrote:
| Great and very interesting writeup! Not sure if that's more
| "Breaking" than "Deconstructing", but still it's very insightful.
___________________________________________________________________
(page generated 2025-06-24 23:02 UTC)