Seems to be a common misconception, passkeys need not be tied to a device, they can be saved to a password manager and synchronized.

This prompted me to read more about it as I was quite certain this was the reason I had stopped using them. It seems the initial wave of complaints fed into some change about a year after the initial launch. Android 14 (Oct 2023) via the new Credential Manager API and iOS 17 (September 2023) when 3rd parties could actually be a registered passkey provider.

https://developer.android.com/about/versions/14/features#cre...

https://www.dashlane.com/blog/dashlane-passkey-support-ios#:...

Perhaps passkeys are more viable now with these changes? I'll need to give it another go and see. Thanks for the tip!

I've been using them with my BitWarden/VaultWarden setup now for a while. I was also extremely crabby about the idea of tying my accounts to hardware to the point of being unwilling to use them, but this problem is resolved. The resulting user experience is now the best of any login methodology and I remain in full control of my passkeys, up to and including the ability to back them up. I think it sometimes takes a "Never Offer Me Passkeys" from the browser sometime, just like they default to trying to get me to save my passwords into their vaults (and I always have to look up the magic setting to tell them to stop doing that on a new install), but it hasn't been that hard to make work.

I think I've heard that the passkeys providers have an option to force it to be hardware, but I've yet to encounter that, and it would also make me quite cross without a very good reason. I, personally, do not want my accounts tied to any particular bit of hardware, I want it tied to the single (very!) strong password I use for everything.

Edit: Browsing through the rest of this HN conversation it seems the password managers have some PR to do. Many HNers are not aware that password managers, even perhaps the one they are already using, have the ability to store passkeys in them. If HNers don't know, certainly outside of the HN bubble it must be even less well known.

The passkey pitch needs to incorporate this. Last time I paid attention, which was a long time ago, passkeys were non-portable. This is a deal breaker for me, so I wrote the whole thing off. I guess they fixed it.

> I think I've heard that the passkeys providers have an option to force it to be hardware, but I've yet to encounter that, and it would also make me quite cross without a very good reason. I, personally, do not want my accounts tied to any particular bit of hardware, I want it tied to the single (very!) strong password I use for everything.

If the functionality is built in, don't be surprised when they alter the deal and force it on you. What are you going to do if no one lets you use or migrate back to a username / password at that point?

We've seen the same thing thousands of times from big tech. They give us a system that's tolerable, but designed to leverage us into a bad position in the future. Once there's a critical mass, they'll flip the switch and we'll all get screwed.

We already saw something similar when 'Login with OpenID' became 'Login with Google/Facebook/Twitter'

I'm not sure that the big players have a motivation to force us to hardware. If anything, a lot of these entities will be happy to not have you forced to hardware because it's a support headache when people lose hardware.

(Also, be sure to understand that being forced to hardware is not "you must use a phone"... it is specifically "this passkey is locked to this Yubikey and can not by any means be moved to any other device". I don't think we're going to be stuck on that. Plus I haven't dug into the protocol but I'm not sure anything stops BitWarden from just claiming to be hardware.)

That said, my eyes are peeled, and at the moment the momentum is in the other direction, in that they actually headed away from that.

It surprised me too since I thought the whole point of passkeys is that you're using a thing-you-own to authenticate, but really the whole point is that the security credential is never transmitted to the service doing the auth.

That’s not the (entire) point of passkeys/WebAuthN at all!

It’s a pretty powerful/complex spec allowing various use cases, from a modern way to store SSH keys on hardware credentials to a more usable and less phishable password replacement backed entirely by software.

I use them for a bunch of things on a bunch of different devices/OSes and one light frustration I've had is I've accidentally stored a few of them in different apps because I'll be on a different device and either not have access to an app that I usually put the key in (1pass) or I'll mistakingly hit a "save passkey" that Windows, or Chrome, or whatever pops up. I've had to go in a few times and change my devices.

I think this is because it's so new with these apps. 1password acts really strange with them sometimes and my chrome extension will lock up or not actually push the passkey through or whatever it does. Sometimes I just get annoyed and throw it wherever worked.

When they're flawless they're awesome. I don't mind the quirks right now.

Synchronized using what service? What's the authentication mechanism that would allow you to download your passkeys from this service?

Various password managers. They're just private keys. Optionally you can use a private key that is kept in a secure enclave on-device, these would not be synchronizable.

And how do you protect the password manager, with a passkey that needs to be stored in another password manager, or with a password with all the security risks that come with it?

A hardware security key, or ideally three, one of which securely stored somewhere, can be a good choice here

KeepassXC works great for this.

I in fact do this with Bitwarden on a daily basis.

It works ok!