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

[cyberax]

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

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.

[cyberax]

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

[ndriscoll]

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.

[lxgr]

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