[vorpalhex]

Rearranging deck chairs on the titantic.

This whole scheme depends on either users being savvy enough to do vault backups or depending on service providers being functional.

Both are quite doomed.

Users have a path for passwords - they can write them down on paper and keep them with their important things. This tends to work for most folks.

The backup story for passkeys is horrible. There is no path for my elderly relatives who don't use cloud services.

Until that is fixed, passkeys will never replace passwords.

Don't forget password sharing! That is a whole screwed up story with passkeys too.

[skarra]

Passkeys represent the cumulative wisdom and experience (and compromises!) of the whole industry on how to keep users safe online. Appreciate your opinions that these efforts are doomed. It is safe to say, "We'll surely find out!"

[vorpalhex]

"The Industry" also has interests like making password sharing impossible, uniquely tracking users and _doesn't care_ if users get locked out.

The industry does not put users first. It puts it's own risk reduction first.

[skarra]

Did you know that Apple allows sharing passkeys via Airdrop?

[kiwijamo]

Doesn't that give access to everything you've signed in using that passkey? Rather than e.g. Sharing the password for the family Netflix account.

[rkeene2]

No... A passkey is specific to a context (RP), which is why they're not stored on things like Yubikeys (which I think a lot of people in this thread are confused about -- the keying material on the Yubikey isn't enough to create the passkey).

Your Netflix passkey is not the same as your passkey to other services. It's generated as soon as you enroll the passkey with Netflix (by calling "navigator.credentials.create()") and is identified by an opaque handle and also the public key (this is important, because you never get the public key again so you must keep both of these: the ID, and the Public Key, otherwise you can't verify a challenge-response, since you're only given an ID and a Digital Signature at that point).

For a site to use a passkey it calls "navigator.credentials.get({ publicKey: { challenge: ..., rpId: "<same_id_as_used_when_creating_like_netflix.com>" }, mediation: "silent" })"

Which returns the key ID and a signed version of the challenge, or an error.

Everywhere you authenticate you have one or more keys, identified by these opaque handles which are stored in the User Agent and associated with some mechanism for performing digital signatures with that unique key. The User Agent, generally, has to store and distribute this information if you want to use the same passkey across multiple devices -- even if you're using a Yubikey (because, again, it's not storing the key being used for the digital signature, it's storing a private key which is used in the process of generating the digital signature, but not the passkey's actual private key -- i.e., the secret part of the public key generated earlier)

[vorpalhex]

Only if you exchange contacts first and are ah.. in Airdrop range.

Your grandmom probably isn't gonna be airdropping a Netflix password.

[xg15]

Can I print out the passkey as a QR code and scan it back in on a different device?

[CogitoCogito]

> Passkeys represent the cumulative wisdom and experience (and compromises!) of the whole industry on how to keep users safe online.

That is true _if_ you do not highly weigh all the concerns that have been brought up in this thread today. I do not trust Google to help if things go wrong so why would I ever consider such a system wise? Frankly, you seem to be ignoring concerns if they contradict your belief that this system is better. I'm reminded of Upton Sinclair.

[pseudalopex]

Did you see they worked for Google? Or did you guess correctly?[1]

[1] https://news.ycombinator.com/item?id=37833206