[skybrian]

Seems like you wouldn't want to share passkeys for the same reasons you don't normally want to share passwords?

Instead, each website that accepts passkeys should allow you to register multiple devices and probably print out backup codes as well (for the especially important accounts).

If there's no reason to migrate anything then lock-in is irrelevant. Just add more login methods so that when you lose some, you have others.

[jjnoakes]

I have over 500 online accounts. Imagine if all of them used a login method where I had to have backup devices registered, instead of just me backing up the credentials (like I do today with a password manager).

With backup devices, whenever I upgrade or replace a device, I need to go to each of the 500+ online accounts and register the new device. This is much more work than a quick login to each site via my password manager (which can happen on-demand, only as I need to use the services).

[stavros]

WebAuthn credentials can be backed up, if you want. They can also be impossible to back up (and thus steal), if you want. It's up to you, which is more than I can say about passwords.

[jml7c5]

Do you know of any implementations that allow this? I've been looking around and even Yubikeys can't do it.

[pabs3]

See the virtual-fido project I posted elsewhere in the thread.

[jml7c5]

Thank you!

[skybrian]

Yeah, this is why I connect unimportant accounts to Google or GitHub, and use two step auth only for the important ones.

[dickhardt]

I founded Hellō to solve this problem. A neutral service where you get to choose how to login, and how you can recover your Hellō Wallet. Done.

See Show HN post I wrote this morning https://news.ycombinator.com/item?id=33178285

[jml7c5]

I think you've pasted the wrong link.

[rohanharikr]

https://news.ycombinator.com/item?id=33177705

[dickhardt]

doh -- https://news.ycombinator.com/item?id=33177705

[throwaway41597]

The lock-in is very real and relevant.

Websites already have a hard time to get users to sign up, so requiring them to enroll backup authenticators (which they won't have) is not going to work. Printing or writing down backup codes is even worse from a UX point of view.

IIRC the spec has a flag to hint that the passkey is backed up (in iCloud or your Google account) so the relying party (website) knows whether backups are mandatory but that means the secret doesn't stay on your device and goes to the mothership. Then I don't see why the spec wouldn't standardize the transfer of secrets from one company to the other.

[skybrian]

That's a good point, but on the other hand, this "lock in" doesn't seem worse from how Chrome generates and saves passwords now?

It would be ideal to set up backup auth before you need it, but you could also do it when you decide to move off Google.

So, not really a lock. It's a vulnerability, though, if you lose access to the Google account for some reason.

[throwaway41597]

Chrome allows you to export saved password in CSV (chrome://settings/passwords) So I'd say it is a regression in this regard. You won't be able to switch to an other browser easily, you'll have to go to each websites and change/add authentication methods as far as I know.