[dotancohen]

  > Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).

I have just shy of 2000 site credentials in Keepass. Let's assume that they were all Passkeys.

1) When I buy a new device, how do I create 2000 new Passkeys for that device?

2) Can I still do that if I don't have access to the old device? Maybe it was destroyed, stolen, or lost.

3) How about if the new device is from a different vendor than the original device? E.g. switching from Apple to Android?

[crote]

The original U2F tokens didn't suffer from this problem that much. It contained one secret, it relied on the website to store and return an opaque website-and-account-specific blob, which was decrypted by the token and used to sign the login request. It would be reasonably easy to expand this in a way where the server also stores a backup credential for use by your second/third/whatever hardware token, encrypted with an asymmetric key during the enrollment of the primary token.

But this went out of the window when some genius decided that usernames were too complicated, so Passkeys had to be discoverable, which means they have to be fully stored token-side. Which of course has the nice side benefit of essentially killing hardware tokens and forcing people into using their Android/iOS/Windows device for it.

[chimeracoder]

> But this went out of the window when some genius decided that usernames were too complicated, so Passkeys had to be discoverable, which means they have to be fully stored token-side. Which of course has the nice side benefit of essentially killing hardware tokens and forcing people into using their Android/iOS/Windows device for it.

This part of your comment is incorrect. Discoverable Webauthn absolutely can be used with hardware tokens like Yubikeys.

[omnifischer]

This. I would have loved if this original u2f existed. Google has even removed this from their accounts.

[Itoldmyselfso]

Passkey comprises of public key that the website you created it on holds, and the private key you store on your pw manager or in the TPM/secure element. As long as you can copy the private key to the new device, you don't need to recreate the whole passkey. In your case, you would just need access to a backup of the Keepass database in case you lose the device.

The biggest point of confusion in my opinion comes from Windows especially having lacked a way (and kind of still does) to save the private key of a passkey to your password manager, defaulting to saving it to Windows Hello, which saves the private key to your PC's TPM. In this scenario you can no longer easily copy the private key to other devices, and if you lose that Windows PC, you also lose the private key and the whole passkey as a result.

[pseudalopex]

People who say users should not be able to export keys are not confused. They believe users should not be able to export keys.

[Itoldmyselfso]

I was referring to confusion experienced by people new to the passkeys creating passkeys for the first time ("Where am I saving this to?", "How do I store this in my password manager?").

[ivlad]

You don’t. You don’t store anything at all.

On registration, a keypair is generated, then the private key is encrypted with the long-term key burned into your security key fob or hardware. The encrypted blob is sent to the server and stored there.

On authentication, after you enter your login, the server sends the encrypted blob and your security key tries to decrypt it with the long-term key it has. If it succeeds, it then request a challenge from the servers, signs it along with the server name and timestamp and sends back to the server. Server validates the signature and if it’s good, log you in.

Expanded: As long you as the user has the security key fob, you can login. You should have 2.

[doodlesdev]

> You don’t. You don’t store anything at all.

Yes, you do.

Whenever a website offers to create a passkey, it could end up in any of these:

- Samsung's Password Manager (if using a Samsung phone)

- Apple's Keychain (if using an iPhone)

- Google Password Manager

- Your operating system's keychain

- A bespoke password manager (e.g., Bitwarden or LastPass)

- Your hardware key

Most users do not have a security key fob. Instead, the proposal being mostly pushed is the idea that users can store keys on their own smartphones, making use of the modern TPM and chip security. Most of the discussion here revolves around that idea: "What if I lose my phone? What if I switch phones?" and that's why the problems seem so obvious to you.

I absolutely agree the best solution is to use hardware keys, but I'll admit it's cumbersome if I need them for hundreds of accounts (which I do have), having to register both for every website and praying that I never lose both at the same time in the case there's no viable recovery flow for some of the accounts. Also, most of these hardware keys are limited to 25 or 100 resident keys, which again makes them unable to substitute passwords. Observe the usage of the term resident keys: passkeys do rely on the private key being stored on the hardware key, as that allows discovery.

[ivlad]

I was talking about the non-resident FIDO keys. “Passkey” term is meaningless unfortunately because FIDO Alliance did not define it initially, it was a marketing term invented by Apple and then re-introduced (or shoved down the throat) by the FIDO alliance.

In non-resident keys scenario you don’t store anything and from what I see there is no security downside of using non-resident keys.

Loosing both (or multiple) security keys is like loosing all your car or home keys. Very inconvenient, agreed.

Anyway, I think we can agree that FIDO authentication protocol implementation is a mess. Apple and Google made it messy because they wanted to lock down users to their platforms and then password managers followed. As a result, the current implementation is not more secure than “login with Apple” or “login with Google”.

[zdp7]

I have to think people aren't doing any research. Both Android and Apple sync your passkeys to your account. You can toss all your devices in a wood chipper, buy a replacement and still have access to all your passkeys.

[pseudalopex]

dotancohen would not be allowed to store Passkeys private keys in a Keepass database in the case thewebguyd specified. Relying parties would block password managers which allowed this.

[zdp7]

1) Install a keepass client and use it for passkeys.

2) See #1

3) See #1

KeepassXC supports passkeys. They suggest a couple mobile apps that also do.

[samrus]

How easy is it to switch off keepass? And how easy is it to export off whatever you imported to? Passwords are simple, just remember the text. Passkeys have alot of uncertainty around this

[ilchalpenl]

> Let's assume that they were all Passkeys.

Lets assume I put all the effort to explain.

I will give you a better example.

- Lets say you have a google account with pixel phone

- You are using it and added 1000 passkeys

- All are synced to your Google account

- Destroy and Get a new phone. Login to your google account with recovery code.

- All your passkeys are in your phone again.

There are plans in fidoalliance.org to make it portable. Pretty sure you are still not going to move to it.

[sandmn]

It works fine until Google suddenly decides that your new device is not you and asks you to confirm login from previous device...

[account42]

Or until Google decides that you did a wrongthink and bans your account, including locking you out of your old phone.

[ilchalpenl]

See.. the sad thing for doomsayers like you is that if even 1% of users were affected then there would be mass exodus from Gmail. It does not.

Yes, you don't use Gmail so it does not matter. You may be don't know. And often even average Joe some how has a oldphone or iPad that has oldgmail account there or logged into wife's phone or phone based SMS whatever.

it is ok to hate passkeys or google or love only self-hosted but let others do what they want.

I have been user of solokeys (since the first one) - only opensource hardware keys. works for me...

But if you go to the local highstreet then there are tons of people doing this screenrepair etc just to recover the account. Average Joe doesnot mind paying for that. Even will give the repair guy full password to transfer all data from old to new phone.

[ilchalpenl]

Apple's keychain or google password manager - can hold 2000 passkeys easily.

[blochist]

Nothing in the post you're replying to is about "is 2000 passkeys storable", it's about "if I have 2000 passkeys and I need to move between an Apple device and an Android device, do I need to establish a second set of 2000 passkeys"?

[ilchalpenl]

Not at the moment. But if you sign into google account in iPhone then you can use Google's passkeys in iPhone.

At the end, passkeys are built not for the tin-foil, (I hate Google Apple fellows), I want to keep every single locally, RMS fans. No.

A majority will benefit. End of matter.

A majority don't change platforms (I have not seen them do it).

And lets be honest - even if they were portable are you privacy person that is going to do it? No.

[TeMPOraL]

No, the majority will not. If through some miracles, passkeys gain sudden and wide adoption, there will be a day of reckoning come around the next mobile refreshment cycle, maybe earlier.

People break their phones. That is normal experience. Entirely unsupported by passkeys as they are today.

I'm actually surprised we didn't have more pushback for ubiquitous 2FA, as they have similar threat profile - i.e. addressing the tin-foil threats of cybersecurity aficionados, while entirely ignoring the common threats to real people, in particular the one of broken or lost mobile device.

[coffe2mug]

Incorrect. They break but they fix it.

People break their phones less often compared to telling them keep their keepassdatabase in sync across devices.

Even recently my friend fixed his iPhone XR (10 year old) 3rd party. Everything including passkeys work fine.

[nightski]

No you don't. I use the same passkeys for all my devices sync'd with bitwarden.

[crote]

Exactly. Bitwarden, not the Apple/Google/Microsoft keychain. That's the problem.

[chews]

Dunno why the downvotes, if you're willing to trust Apple or Google this is a good method for passkey usage. because your touchID/faceid/opticalid auth gate the keyring's on either of these vendors your passkey works without having to migrate them. EDIT: Also ANY device that you add to your iCloud has access to the passkeys you've made... it's a dream for secure access.

[dotancohen]

What happens when the user decides to move to an Android device, or even is suspended from Apple for a suspected breach of the terms of service, or Apple decides to not support their country anymore? There are countless reasons to prefer to manage one's own access.

[ilchalpenl]

True... Theoretically correct but in practical sense?

All these doom mongering of suspension happens so rarely that majority don't care.

There are countless reason to DIY. Agree. But passkeys will help the majority.

Also note that the kind of people - like journalists etc - that need to use DIY/local are the ones that are likely to use passkey. Reality.

[ilchalpenl]

Downvotes does not matter. People here that are privacy inclined always find ways to argue about Google or Apple (any major companies). But if you look at their private lives - they adopt tech ASAP. A majority have Apple Pay or Google Pay. Paypal. At the same time use bitwarden also. (And that is fine)

These privacy zealots fail to realise that majority of population does not have time to setup bitwarden server or lineageos or zfs storage etc.

[fugalfervor]

The downvotes are because the commenter did not read or at least did not fully comprehend the meaning of the post they were responding to.

[Petersipoi]

Did you not read the comment thread you're responding to?