is passkey any better than a password manager, besides losing the option to set your own secure password that you can store offline?
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.
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.
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.
what?! standards are the opposite of flexible. by definition.
here's something that is better than webauthn, published and battle tested since 2018, and nobody cares: https://hacks.mozilla.org/2018/11/firefox-sync-privacy/
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.
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.
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.
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.
Hence the question.
I hedge some about my understanding of the current WebAuthn/FIDO/Passkey standards as my view of the Passkey model is still somewhat filtered through my old understanding of Keybase's "sigchain" model when they moved to device-based keys: https://book.keybase.io/docs/server#meet-your-sigchain-and-e...
So far as I'm aware, Passkeys doesn't deviate too much from how Keybase had been built post per-device keys [1], albeit with more OS/platform support and fewer blockchain/cryptocurrency distractions/acquihire-risks.
There are a hierarchy of keys (and yes it is generally always N keys involved and a complex keychain; websites may not see the whole keychains, though) with the most trusted being the keys that are non-exportable and therefore hardware device-specific. (Those keys get additional "attestations" attached specifying those extra trust characteristics.)
Every one of a user's devices would generally learn and cross-sign each others public keys to recognize each other. There's a definite N key relationship between them.
Device keys are then used to bootstrap more keys.
Each subkey is more ephemeral (shorter expiration date) and less "trusted" than the last. These subkeys may be website-specific. These subkeys may or may not be shared between devices. When shared between devices it may be peer-to-peer, device-to-specific-other-device, end-to-end encrypted with device-specific keys. When shared between devices it may not even be in the form of a key but a shared "pepper" (relative of a hash "salt") to be mixed with website-specific call/response into a key-derivation function (KDF) of some sort. The keys may not be shared at all and instead a CA-like approach is used that if the subkey is signed by a known device key it is accepted. The keys may not be shared at all and instead data to be signed is sent encrypted to a specific device (a roaming phone, for instance) and that device signs it with a hardware key then encrypts that for the requesting device's ears only and passes it back over close-proximity-only Bluetooth LTE. Or nearly that same thing, but data being signed is a temporary key from the originating device.
Additionally, vendors may add their own keys to the keychain for easier "recovery" in "Forgot Password" situations. Many of these keys might be subkeys of some cloud-based HSM and shared in similar ways (directly to specific devices after handshaking on device-specific, unexportable keys; KDF-built using a combination of "pepper" secrets known to the user and known to the cloud provider; some other thing).
All of this is highly implementation specific which specific strategies are in play in any given interaction. It will likely also be highly vendor specific which ones they prefer. It is also somewhat website specific: websites are allowed to suggest they are "important like a bank" and will only accept the most highly attested keys (the non-exportable, device-specific kind). Websites might only want one-or-two degrees maximum distance from a highly attested key. I believe in rare situations websites might request as much of the signature graph as they can.
The whitepaper [2] shows the two "new" WebAuthn Level 3 "use cases": lots of device keys sharing some more ephemeral keys. Lots of devices referring to a single other device for keys. Passkeys uses both/either as needed.
To properly support Passkeys doing ephemeral key tricks, websites do need to store N keys per user, but that's always been a soft-requirement for good WebAuthn support. (In the case of secure FIDO tokens well before Passkeys, there's no recovery path without N key support.)
In general, a User's "passkey" is most likely never represented by only a single shared private key, it's an aggregate hierarchy of keys from non-exportable device keys to temporary keys shared between devices to ephemeral keys made of "salt and pepper" and everything in between. Lots and lots of keys that generally know/trust each-other is much easier to secure than one-key-to-rule-them-all. There may even be as many as N * M keys in cases where every website has a different key for every user device.
Long story short: "[they] don't sync private keys, they sync and cross-sign public keys" is subtly wrong short-hand because they may sync all kinds of temporary/ephemeral private keys and/or private data device-to-device. But even given ephemeral private keys it still feels more to me, and my understanding/my ability to elucidate my understanding, like describing that as cross-signing public keys as the "simple, short answer" rather than list all of the surprisingly many and complex ways they might be created and/or shared.
[1] https://book.keybase.io/docs/server#meet-your-sigchain-and-e...
[2] https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho...
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.
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.