To put it another way, it's not really any more secure than passwords.
Sure, there's a lower risk of password breaches, but if you're the target audience for passkeys, you probably also use a password manager with unique passwords per site (even if that manager is the one built into your browser and synced across your devices).
True if you are being specifically targeted, but there are whole classes of vulnerability that you are better off not having even if you have less than perfect opsec. To take an extreme example, my personal server may have an unpatched vulnerability that a determined attacker might exploit, but that doesn't imply I might as well share the same password across all my accounts.
Irrelevant to the argument I made. My argument already assumes you're using unique passwords, since it's made quite simple these days.
Good passwords (stored on the backend with a password-optimized hash) are pretty close to bulletproof, and all browsers that I've used in the last few years prompt you with very good passwords.
Again, the key is that people who would use passkeys are the same ones who will be using good, non-reused passwords in the first case. We've taught non-technical users too well that they should not pay attention to out-of-browser prompts, so they're not going to be able to use passkeys without significant and broad re-training.
This is the difference. With the big players pushing it, including Apple instructing developers on the best way to integrate passkeys in their apps[0], it's going to overall shift more people from passwords to passkeys (especially when developers prioritize passkeys during signup).
0: https://developer.apple.com/documentation/authenticationserv...
Chrome and Edge on Windows are the only ones that prompt me for passkeys today (Firefox tries to use Windows for auth, which throws up a scary prompt).
> Already webauthn isn't prompting for passkeys on Apple.
It does for me on iOS, at least (and Safari on MacOS; other browsers don't use the native icloud passkeys, chrome has its own secret store).
> Chrome wants a bluetooth connection out of the box,
IIRC it works without it for on-device passkeys, but caBLE requires Bluetooth to facilitate proximity passkey connections if you want to use wireless webauthn.
> but caBLE requires Bluetooth to facilitate proximity passkey connections if you want to use wireless webauthn.
And that's the problem. The lack of a cross browser/device/os standard. You can't create a secure authentication chain - let alone replace passwords - without standards that are broadly accepted; without broadly accepted standards. To do otherwise means you have to train your average Jack on 4 (or more) different ways to authenticate to one service.
And the way they'll pick? Passwords. Because they know how to use passwords.