[rektide]

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.

[alsdfjkslfheu]

> 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.

[tadfisher]

Firefox syncs passwords, not keys. Passwords can be reused, stolen, or leaked, all of which cannot be done to WebAuthn keys.

[crote]

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.

[WorldMaker]

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.

[SgtBastard]

> 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.

Hence the question.

[WorldMaker]

From my understanding, it's complicated to find a way to say it never does a certain thing because Passkeys technically checks the "All of the Above" box and does a little bit of everything PKI can do, because it is explicitly multi-strategy for redundancy/resiliency/speed/ease-of-use reasons.

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...

[rektide]

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.

[gtirloni]

1Password has passkeys in beta.