[labadal]

I love passkeys. I love them being on my phone, requiring biometric authentication before unlocking. I just hate the vendor lock in that comes with it.

Does anyone know the state of the standard wrt this? I know that they planned on doing something about it, just haven't kept up.

[normalaccess]

I use Bitwarden to store my passkeys. Syncs to all my devices and just works. I have very few issues with it. Also for the truly paranoid, you can run the open-source back end on your own server if you want.

https://bitwarden.com/passwordless-passkeys/

[secabeen]

Can you export the passkeys to an importable form that your heirs can use to get into your accounts if you have passed away? Something that's sealed in an envelope inside a fire safe, for example?

Every vendor I see offering a solution has no documented export option at all. Yes, you can use the legacy method to login, but an authentication stream that is not used regularly is one that will break, or will ask for a factor that I no longer have access to (I wouldn't know this because I only use passkeys.)

I also expect that there will be sites that only accept passkeys eventually, even if the spec says you shoudln't.

[lolinder]

What do passkeys synced over Bitwarden get you that a username + random password does not?

[udev4096]

It's not paranoid to host your own password manager. It's about not relying on Bitwarden for the most critical service without which I am locked out of pretty much everything. Plus, you get lots of cool features that are only available on bitwarden premium

[vngzs]

I can register my Yubikeys on account.google.com (and around the web, e.g., fastmail.com) as passkeys. If you visit the account security page[0] and enable "skip password when possible", then you can log in to Google with only a Yubikey-backed passkey.

If you have old Google creds on your Yubikey, you may have to first remove those creds from your account (because there are older and newer protocol choices, and with the old protocols enabled Google will not support passwordless login).

Multiple yubikeys are required if you would like to have backups; there is no syncing between keys.

For support matrices, see [1].

[0]: https://myaccount.google.com/security

[1]: https://passkeys.dev/device-support/

[godelski]

  > there is no syncing between keys

This seems like a key failure point to me and why I've been a tad resistant[0]. If there isn't some form of automatic backup then I guarantee I will not have a sync when I need it the most.

There is a similar problem even in OTPs. I switched phones not too long ago and some OTPs didn't properly transfer. I actually lost some accounts due to this, luckily nothing critical (I checked critical things but it's easy to let other things slip). The problem is that registering a new OTP removes the old ones. In some cases I've used recovery codes and in others the codes failed. IDK if I used the wrong order or what, but I copy-paste them into bitwarden, and I expect this is typical behavior.

99% of the time everything works perfectly fine. But that 1% is a HUGE disruption. With keys, I would even be okay if I had to plug my main key into a dock to sync them. Not as good as a safe, but better than nothing. I feel like we're trying to design software safes like we design physical safes. But if you lose your combo to a physical safe you always have destructive means to get in. With digital, we seem to forget how common locksmiths are. Googling, numbers seem kinda low but I'm not in a big city and there are at least 4 that I pass by through my typical weekly driving. So it seems that this issue is prolific enough we need to better account for actual human behavior.

[0] Don't get me wrong, I love them but I'm not willing to not undermine them via OTP creds because I need some other way in.

[AnotherGoodName]

You can also simply register all your devices individually as a passkey and login with any one of them. Part of the point of the passkey standard was that you can simply have your laptop/phone/etc. act as a Fido2 backed security key in its own right. So if you have multiple devices it's pretty easy to set them all up as your passkeys.

Eg. My Microsoft desktop, my Google phone, my Apple laptop all have passkeys setup individually that allow login to my various accounts such as my Google account.

So they aren't at all synced. They are all from different vendors but they can all login since i set them all up as passkeys. It's easy to do this too. Setup one site for passkey login via phone, go to that site on your desktop and select "auth via phone passkey" and use the phone passkey and then once logged in on the desktop go to account setup and select "Create a passkey on this device". The end result is you have multiple hardware security keys, namely your phone, desktop and laptop.

[zikduruqe]

I just use a Trezor One (yes, a bitcoin hardware wallet).

I back up my 12 word seed phrase, and then I can restore any and all my TOTP/FIDO/passkeys with another one if needed.

[kccqzy]

I tried setting this up for a non-technical friend who was gifted multiple brand new Yubikeys. The goal is to log in to Google using any one of the Yubikeys with no password. Unfortunately doing so causes Chrome to pop up a dialog requesting a PIN for the Yubikey. How did you solve that problem?

Searching online I found an answer on Stack Overflow stating that a PIN is required in this case: https://stackoverflow.com/a/79471904 How did you bypass it? I also find it idiotic that it is required. A PIN is just a password in another name, so we are back to using Yubikeys as the second factor in 2FA rather than a password replacement.

[taeric]

I always ask how you expect to defeat the vendor lock in?

Effectively you have a secret that you are using to authenticate yourself. With pass keys managed by a vendor, you are trusting that vendor to manage your secret. If they are able to give your secret to someone else, then they can no longer confirm who all knows your secret.

I'm sure you can come up with a protocol where you can fan out access to the secret in a way that requires fanning back messages to you. But I don't see any clear way to do so that doesn't increase the communication burden on everyone.

I'm also sure smarter people than me can surprise me with something, here. But secrets that can be shared historically tend to not be secrets for long.

[blibble]

> I'm sure you can come up with a protocol where you can fan out access to the secret in a way that requires fanning back messages to you. But I don't see any clear way to do so that doesn't increase the communication burden on everyone.

the spec actually supports this, it's called caBLE

[udev4096]

Do not use a vendor for managing passkeys. Use a self hosted password manager like vaultwarden. Or spin up an OIDC provider with pocket-id. Using a vendor is just pointless and should be avoided at all costs

[shellcromancer]

The FIDO Alliance (who wrote the WebAuthn spec with the W3C) has a draft specification for a format (Credential Exchange Format) and protocol (Credential Exchange Protocol) for migrating passkeys and other credentials [1]. I don't think this is implemented by any providers yet, but it's being worked on.

[1] https://fidoalliance.org/specifications-credential-exchange-...

[conradev]

The big remaining issue in my mind is this one:

https://github.com/fido-alliance/credential-exchange-feedbac...

I am worried about providers blocking exports “because security”. That’s Apple’s favorite argument

[namro]

On Android, Keepass2Android developer is working on supporting passkeys in the near future (https://github.com/PhilippC/keepass2android/issues/2099) but I'll be honest, I haven't dedicated enough time learning about passkeys to be sure the app will be able to support all implementations of passkeys and avoid vendor locking completely.

[supportengineer]

For me, the only thing that makes passkeys viable is backing them up in the cloud and automatically syncing them across devices. Otherwise, I do not trust them.

[TechDebtDevin]

What do you use?

[johnisgood]

I'm not sure if this is satire. You trust the "cloud" and whatever does the syncing to the cloud? I definitely don't trust anything that "syncs to the cloud".

[an_d_rew]

1Password integrates with all pass keys on my iPhone, my Mac, and my Linux box.

By a far and away WORTH the subscription, for me!

[drdrey]

doesn't that mean your passkeys are now about as secure as a regular password?

[udev4096]

Imagine using the worst password manager out there. 1Password was breached several times and even led to some people losing significant amount of money

[hiatus]

Can you expand on the vendor lock aspect? I have stored passkeys in my password manager, so they feel pretty portable to me. Is it that each service requires a unique passkey? That seems comparable to how each service would require its own TOTP seed.

[supportengineer]

Your password manager came from a vendor. As a thought exercise, switch vendors.

[Steltek]

From the article:

> But how can websites know whether its users are using secure authenticators? Authenticators can cryptographically prove certain facts about their origins, like who manufactured it, by generating an attestation statement when the user creates a passkey; this statement is backed by a certificate chain signed by the manufacturer.

How many scummy companies trot out "Let me protect you from yourself" to justify taking away their users' freedoms?

[idle_zealot]

> Does anyone know the state of the standard wrt this?

Exporting/transporting keys seems to be optional on the part of implementors, but my solution has been to use Bitwarden, so I at least get cross platform keys.

[jp191919]

I use KeepassXC on my PC. Not sure of an app for mobile though.

[yladiz]

Unfortunately I don’t think there’s much to help with vendor lock in directly (like, you may or may not be able to export the private key(s) depending on the tool, and in some cases it’s definitely not possible like with a hardware key), but any website that supports passkeys supports WebAuthn in general so you shouldn’t have difficulty migrating to another tool if desired, although you would need to register again.

[reginald78]

Passkeys support an attestation anti-feature, enshrined in the spec. This feature can be abused (and will be IMO, why put it in the spec otherwise?) to limit which providers can access a service. Lock-in is built into the design.

One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.

[iknowstuff]

https://strongboxsafe.com/