[Ajedi32]

> Now one could allow backups of a passkey

That's literally part of what makes a passkey a passkey (v.s. just a WebAuthn credential), so that's a given.

> as insecure as a password

No. Passkeys can't be phished, passwords can. Passkeys can't be cracked after a data breach. Passwords can. Passkeys can't be set to something easily guessable. Passwords can. Passkeys can't be written on a post-it note and taped to your monitor. Passwords can. Passkeys can't be reused across multiple sites. Passwords can.

There are so many ways passkeys are superior to user-memorized passwords from a security perspective, it's laughable to call them "as insecure as a password".

> One could allow multiple instances of authorized passkeys, but those would be even more insecure than passwords, because malicious software on your device could create evil new key instances.

What? Malware stealing your password is "more secure" than malware registering it's own malicious key to each individual site it wants access to?

[awaythrow98765]

> No. Passkeys can't be phished, passwords can. Passkeys can't be cracked after a data breach. Passwords can. Passkeys can't be set to something easily guessable. Passwords can. Passkeys can't be written on a post-it note and taped to your monitor. Passwords can. Passkeys can't be reused across multiple sites. Passwords can.

Passkeys don't need to be cracked after a data breach of your backup provider, they are just usable, right there.

> There are so many ways passkeys are superior to user-memorized passwords from a security perspective, it's laughable to call them "as insecure as a password".

Passkeys are accessible permanently on some devices unencrypted or decryptable in the filesystem, if part of e.g. a backup. Whereas passwords are usually only accessible temporarily. That makes the attack surface top copy over some passkey far larger than for sniffing a password.

[lxgr]

> Passkeys are accessible permanently on some devices unencrypted or decryptable in the filesystem, if part of e.g. a backup. Whereas passwords are usually only accessible temporarily.

I think you're mixing up server-side and client/sync-backend-side compromises here.

For the former (i.e. a compromise of hashed passwords and their corresponding salts), you'll need to rotate all passwords since the hashes can be brute-forced. For passkeys, all an attacker gets when compromising a service's database are public keys that can't be brute-forced and key handles that don't give an attacker anything without the corresponding authenticators.

For the latter, the situation is exactly the same for passkeys and passwords in a password manager, i.e. both are as secure as their on-device storage and encryption in transit and rest at a synchronization provider (if any).

[Ajedi32]

You seem to be under the false impression that passkey databases are stored completely unencrypted and unprotected on disk or in the cloud. Obviously those details are implementation-dependent, but I don't know of any passkey implementation that works that way.

Let's take Apple's implementation as an example (since that was the one I could most easily find information on). Their implementation stores passkeys in the iCloud keychain[1], which is end-to-end encrypted[2].

[1]: https://support.apple.com/guide/iphone/sign-in-with-passkeys...

[2]: https://support.apple.com/guide/security/secure-keychain-syn...