[xoa]

Fully managed passkeys will always have the max needed entropy without any need for KDFs, never be reused, are amenable to a smooth path to hardware backing, and most importantly/fundamentally aren't symmetric factors. You don't need to share the private key with the website, and that in turn means that even if you stored it in plain text on your own computer you're still immune to the most common form of leaks which is services themselves getting hacked. Password managers make it easier to change a password after a leak has happened, but moving to a proper key based infra means that leaks simply no longer matter. It doesn't matter in terms of auth if attackers get a public key.

While having more hardware backing on top certainly has advantages too, it's the symmetric nature of passwords that have always made using them in a shared environment a fundamentally bad idea. Practical advantages of moving on like eliminating all the stupid legacy password policies and so on in one fell swoop are nice as well.

>besides losing the option to set your own secure password that you can store offline?

There is nothing inherent that would stop passkeys from being converted to base64 and printed on paper same as any key, and part of the point of them is being able to back them up all the normal ways and have them secured with a good password or other option that never leaves your own control. Which of course you can then print out.

[ljm]

As I recall it, this is more or less what Mozilla wanted to do with Persona back in the day. That didn’t take off, but the approach with WebAuthN is perhaps an evolution of it especially in terms of making public key crypto user-friendly. Of course, the challenge is different in a multi-device world when you want your phone, tablet and laptop to all use the same login without using a hardware key.

[GoblinSlayer]

If the password is properly managed, how does it matter if its hash leaks?

[SgtBastard]

Two major problems with holding passwords server side as hashes: 1) Every authentication attempt needs to send the password as cleartext (even if over TLS) so that the hash can be recomputed server side and compared. This gives ample opportunity for the password to be intercepted either over the wire or compromise of infrastructure server-side. Using asymmetric encryption doesn't have this vulnerabity.

2) Passwords that can be stored in the meatsack attached to the keyboard aren't as random as we'd like to think them to be, where as a secure pseudo-random function will generate keypairs with unguessable entropy.

Expanding on 2) While salting and non-uniform iteration counts of hashes prevents instant compromise from rainbow tables, they only slow down adversaries generating hashes from password guesses, as the salt and iteration count will typically be leaked from the same table as the password hash.

Its worth noting that while it definitely is infeasible to attempt to crack 100K+ users passwords from a password hash leak, using password spraying and especially password stuffing approaches will inevitably lead to compromise one or more accounts relatively quickly. At the other end of the spectrum, if a known high-value account can be identified, dedicating the distributed cloud resources to cracking a specific password can be a net-profitable undertaking.

[GoblinSlayer]

A secure pseudo-random function will generate passwords with no less entropy than your keypairs. Builtin password managers in browsers do that. And if the server is compromised, the attacker doesn't need your credentials at all: he already has more access to the server than you ever had.