←back to thread

Passkeys and Modern Authentication

(lucumr.pocoo.org)
184 points Bogdanp | 3 comments | 02 Sep 25 13:47 UTC | HN request time: 0.763s | source
Show context
AnotherGoodName ◴[02 Sep 25 17:01 UTC] No.45105818[source]▶
> there is effectively no way to export private keys between authentication password managers

No exporting really is a feature. Otherwise people would be tricked into giving away passkeys much like they are with passwords today.

You can always register multiple passkeys with providers though. Already have a passkey with google but want another one via a different password/account manager? Just go into settings on google and add it! This is effectively how you’re meant to move passkeys around. Create a new and register that with the same services as the old one.

The real hassle right now is remembering all the services you attached your current passkey to so you can register a new passkey with them and it’d be nice if there was something similar to ninite installer for passkey registration. But still it's not a huge blocker. You can absolutely use multiple passkeys and login with any one of them.

replies(5): >>45106185 #>>45106728 #>>45106815 #>>45107755 #>>45108712 #
1. palata ◴[02 Sep 25 20:38 UTC] No.45108712[source]▶
I don't get the downvotes here.

I feel like people mix up the protocols and the implementations. Because one can share their passkeys with a Google password manager does not mean that they have to. Passkeys are just WebAuthn, which works on its own.

Since I'm getting downvoted as well: I am using passkeys with Yubikeys, without depending on any TooBigTech.

replies(1): >>45117642 #
2. NoGravitas ◴[03 Sep 25 16:25 UTC] No.45117642[source]▶
> Because one can share their passkeys with a Google password manager does not mean that they have to.

The standard provides the means for the relying party to choose what password managers it will accept, so you may very well have to use the Google password manager.

replies(1): >>45120873 #
3. palata ◴[03 Sep 25 22:04 UTC] No.45120873[source]▶
Without passkeys, a service can force you to use their own proprietary app as a second factor. It's been like that for years with banks and at big companies.

They already do select the security they want. And it does make sense when security matters to them!

Say you managed to put into the law that "it's illegal to discriminate passkeys, either you accept all implementations or none of them". What would happen then? Those services would just not use passkeys, because they already have a solution they control today (with their own authenticator apps).

What the standard provides is a way to have certified/audited passkeys. So that instead of using the authenticator app of my bank to log into my bank and the Microsoft authenticator to log into my company SSO, maybe (just maybe) I will someday be able to use a passkey. Not any passkey, that's very clear, and it actually does make sense in terms of security. But maybe instead of using Apple or Google, you will be able to use a security key like Yubikey.

And the fight should be to give a fair chance to those third-party systems for getting certified. Not to refuse the passkey technology because instead of being forced to use the Microsoft passkey, we really like it better when we are forced to use the Microsoft authenticator app.