[didntcheck]

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?

[parliament32]

> 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.

[jesseendahl]

>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.

[cyberax]

> 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]

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.

[lxgr]

> 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.

[jeroenhd]

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]

> 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.

[lxgr]

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.

[mjg59]

The attestation is purely the MFA token, not the OS

[tialaramex]

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.