I've yet to voluntarily enable passkeys, for the main reason that I want portability, and not to be tied to any single device that can be lost. I want to be able to backup and lock my credentials in a safe. I also want to control the strength of my credentials for different services, and I don't consider my thumbprint used to unlock my phone to be as strong as a long password in a password manager.

The first time I was forced to use a passkey implemented within the vendor's app (3rd party password managers were not an option). I quickly closed that account.

The second time was an app that popped up a passkey opt-in in the middle of a bunch of transaction screens. I quickly realized the error, but there was no easy undo. The opt in was one green button in the middle of the screen. Turning it back off required digging through settings to find the security option to disable, and then confirm my choice multiple times. That process also signed out all my other devices.

The fact that companies are resorting to dark patterns and forced requirements, where my money is held hostage, should be pretty good evidence of how poorly the passkey rollout is going.

▲

BadBadJellyBean 5 hours ago | parent | next [-]

You can put your passkey in another safe. I store mine in my vaultwarden. You can also do keepass with a plugin. You don't have to store it on your phone.

▲

crote 2 hours ago | parent | next [-]

There is no truly secure options for this, unfortunately. Passkeys have to be online to enroll additional keys, so any kind of software or smartphone solution is going to depend completely on cloud sync. Any form of offline copy stored in a physical safe will quickly be outdated.

It gets even worse when you want to have separate passkeys, so that you have the possibility of knowing which one was compromised and doing a partial revocation: the cloud sync now requires every device to have access to every copy, so that you can individually enroll them during registration.

Yubikey of course suffers most from this, as their hardware tokens are physically incapable of any kind of sync, so a Yubikey passkey is very quickly a single-point-of-failure. They proposed[0] a system which would allow enrolling a "backup key" (which could then be safely locked in a vault, far away from day-to-day use), but with the various Big Tech companies pushing their own proprietary cloud-synced passkey implementations that of obviously went nowhere.

[0]: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...

	▲	WorldMaker 35 minutes ago \| parent [-]
		Most website implementations that support passkeys have to support multiple key enrollment. It's the only long-term reliable way for the many, many users that are cross-ecosystem, which especially means Windows users in the age of no Windows Phone. Every Windows user has either an Android or iPhone. You can bootstrap with Bluetooth LTE access to your phone for a Passkey, but it's a rough web experience if the user needs to do that every time they access a page, so most good flows ask the user the enroll a Windows PC passkey in addition to their phone's passkey and really good ones make use of a passkey auto-enrollment option designed for this scenario (Bluetooth passkey to "local" passkey auto-enrollment). Perhaps surprisingly, Windows has helped keep Passkeys from being "proprietary" lock-in because Microsoft no longer has users in a single ecosystem. There is no dedicated auto-enrollment for "backup" keys, but most consumer sites make it very easy to enroll "backup" keys yourself. Also, Passkeys don't have to be "online" to enroll additional keys. Each key is independent, enrolling is just generating new keys. The trouble is that web browsers generate lots of Passkeys (at least one per domain, at the very least) so if you in theory want to print them all and store them in a physical vault it might be a hefty book you are printing. Cloud sync isn't required. Most users want it so that they don't have a single-point-of-failure. As an implementation detail some Passkeys have a master key that is then used in some key derivation function (KDF) to generate the hundreds or thousands of individual passkeys (at least one per domain), and that's what most Yubikey passkey implementations need to do because Yubikeys weren't designed to store lots of keys, so it is devices like Yubikey that makes it seem like Passkeys are less independent than they really are.

▲

eikenberry 3 hours ago | parent | prev | next [-]

What if they meant a real safe? The big metal kind.

▲

embedding-shape 4 hours ago | parent | prev [-]

> I store mine in my vaultwarden.

Can you export it from there? My main gripe with passkeys in 1Password is that seemingly you can't export them, unless you export it to "someone else", which isn't clear if that someone can be just "you".

	▲	limagnolia 3 hours ago \| parent \| next [-]
		If your password vault supports https://fidoalliance.org/specifications-credential-exchange-... you can. (Bitwarden does)
	▲	MrDrMcCoy 3 hours ago \| parent \| prev \| next [-]
		Yes. I've done many imports/exports and have lost no passkeys with Vaultwarden.
	▲	dizhn 3 hours ago \| parent \| prev [-]
		I do not know the answer to your question but mine are in Vaultwarden. This probably means I have access to them. The method to get them out might end up not being pretty but it should be possible.

▲

rkagerer 4 hours ago | parent | prev [-]

Silicon Valley suffers an utter lack of comprehension of the concept of consent. As another commenter pointed out some time ago, if we were in a nightclub they'd be the creepy guy that keeps coming up to you asking:

Want to dance? Yes | Maybe Later

▲

nntwozz 3 hours ago | parent [-]

Silicon Valley suffers an utter lack of respect for the user, it's user-hostile.

I remember that comment, it's perfect.

	▲	pishpash an hour ago \| parent [-]
		It only started with Google.