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.
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.
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.
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.
If nothing else, it has more bits of security than a password has & so is less crackable.
It's also an official standard that should integrate effortlessly into apps & websites alike. Password Managers are- as far as I know- all bespoke solutions with their own custom implementations. Not having a common interoperable framing for implementation & extension limits user's control & optionality.
The other major advantage is that sites don't need to support "Passkey". They support Webauthn. Then the user can use what the user wants to use. If they want to use a hardware key, go for it. If they have a user agent that implements WebAuthn by carving their keys in a stone tablet & using computer vision to read the credentials back, they can use that. Standards enable flexibility which enables possibility.
it have all the advantages of webauthn, plus it is truly on-device, no middle man, you can easily recover keys simply by having more than one device... no server can read or data. only silly thing is that firefox insists on shipping with the auto-fill option enabled by default.
only feature missing that this thread seems to brings up is support for external usb devices (which i personally don't care for, but is probably on the roadmap)
--
i'm blocked from adding replies, so replying here:
> it does passwords not keys
well, that is what worked on 100% the internet in 2018 (and today, ha!). But it is a data store where you have full control. ironically this is what gives true flexibility, a well designed system with fully open source implementation and apis, not spec by ad vendors as claimed before. anyway, The existing browser implementation does passwords (and bookmarks!!!) but you can extend to be a distributed yubikey if you'd like. nothing is blocking you. as I said, it is something better than a hardware store, better than a cloud broker for your identity, etc... but nobody cares. And now that FIDO has marketing from the big Advertisers everyone wants it yesterday.
If I am not mistaken, all Passkeys implementations allow keys to be synced between multiple devices. This means it is by definition possible for them to be stolen or leaked.
Webauthn keys are only secure against stealing & leaking if they are backed by a proper separate token like a Yubikey, but it seems the People That Be want us to get rid of those ASAP.
To my understanding, Passkeys implementations don't sync private keys, they sync and cross-sign public keys.
Some vendors may also add "recovery" public keys to those synced keychains so that you can "Forget Password" your way out of a lost device or locked account or bootstrap new devices, and you have to trust your chosen vendor's security for how they manage that private key for any "recovery" keys.
But my impression is that there isn't anything that Passkeys is doing that you couldn't do by also collecting Yubikey public keys by hand and making your own keychains if you are sufficiently motivated.
> To my understanding, Passkeys implementations don't sync private keys, they sync and cross-sign public keys.
I haven't seen anything in the FIDO alliance or vendor (Apple, Google, MS) documentation to suggest that they're cross-signed public keys - can you point to some that I may have missed?
The reason why I ask is on the face of it, it doesn't make sense to implement in this way: It would mean that each new device would have its own keypair per service and cross signed by at least one other trusted device.
Which could be fine, but now each service needs to store n public key pairs (one per device) after validating that the new key has been signed by a known key.
Then, when a new device is added to the Keychain (in apple's case), that device needs to generate m new keypairs for m services, have them cross-signed and then proactively registered for each service.
It does make sense to implement it as the person you're replying to suggests, where a shared private key is shared over an authenticated, end-to-end encrypted process - with the corresponding weakness that if the authentication method for adding new devices to an existing Keychain is compromised, so are all passkeys.
WebAuthn I think proves quite well how a common abstraction can enable constant ongoing growth & expansion. This case alone is a clear win for standards being a way to get the ball rolling.
Web Standards also tend to define what things look like for the page. They're a common interface for the developer. This does come with some constraints (but often some freedom/extensibility points are baked into specs too). What's notable is that implementation is replaceable. Different browsers can do different things, expose things in differnt ways.
Users can also deploy Web Extensions to modify or monkeypatch or polyfill webapis in ways that they want. This is another key advantage of standards, that they create a common target which is user-instrumentable. Without standards, users are forever adrift & subject to the mercy of the various proprietary implementations.
Cannot be phished by currently known methods. Trust me, sooner or later they will find a way. Either through specific implementation issues, workarounds etc. Remember when everyone shrugged off concerns about sms 2fa codes?
The WebAuthN standard (and corresponding browser implementations) do inject browser supplied attestation of the requesting domain, so only a horribly broken implementation would sign a request for mail.google.hackers.ru with the key provisioned for mail.google.com - the user has no input into what the browser supplies, hence its phishing resistance.
That being said, there's no end-to-end verification of the server, so any DNS-poisoning or proxy-MITM-ing of traffic that presents a certificate trusted by the browser will validly present the Passkey implementation a domain that matches a validly provisioned key, allowing session hijacking or the start of oracle attacks on the private key itself.
Also: phishing the recovery passwords to add a new device to the synched keychain is definitely a thing.
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.