←back to thread

Passkeys and Modern Authentication

(lucumr.pocoo.org)
184 points Bogdanp | 7 comments | 02 Sep 25 13:47 UTC | HN request time: 1.459s | source | bottom
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 #
hooverd ◴[02 Sep 25 19:19 UTC] No.45107755[source]▶
Effectively ceding control of your online identity is a feature? Would you be willing to bet real money that the passkey attestation feature will never be abused be these same companies ?
replies(1): >>45108659 #
palata ◴[02 Sep 25 20:34 UTC] No.45108659[source]▶
How is that effectively ceding control of your online identity?

You can buy a security key (that does not have your name on it), have it generate a FIDO2 key and use it as a passkey. You can have 100 Yubikeys for 100 different websites if you want.

But you can't ever export the private key from the Yubikey, and that's a feature. That's the whole point of the Yubikey.

replies(1): >>45109996 #
tuckerman ◴[02 Sep 25 22:33 UTC] No.45109996[source]▶
I think there is a difference between a specific implementation of passkeys not allowing export as a feature and the article’s linked GitHub thread with a threat of potentially blacklisting an implementation if it allows export [1]. Imo users need the fundamental freedom to choose.

[1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

replies(1): >>45110512 #
1. palata ◴[02 Sep 25 23:37 UTC] No.45110512[source]▶
Where is the threat to blacklist? I missed that so I lack context.
replies(1): >>45111023 #
2. tuckerman ◴[03 Sep 25 00:47 UTC] No.45111023[source]▶
My reading of the the linked github thread is: 1) A member of the FIDO alliance says that provider attestation is bad because relying parties could block specific providers 2) This FIDO alliance member doesn't like that keypassxc has implemented a feature for their users that weighs user freedom/security different than they would prefer and 3) they insinuate that if keypassxc doesn't change this, they could decide to push for provider attestation in the future, potentially ending keypassxc as a viable password manager.

Perhaps I'm reading things in a worse light than you but I believe the potential for abuse is so high and the value of user freedom is so high that these comments shouldn't be taken lightly. I say this a user and huge fan of Yubikeys (I use them precisely because of the feature of not being able to export the private key for security). But I think users have the right to build/use software that works how they see fit.

replies(1): >>45113546 #
3. palata ◴[03 Sep 25 08:43 UTC] No.45113546[source]▶
> But I think users have the right to build/use software that works how they see fit.

They have, I don't think anyone denies that. But the other side has the right to refuse working with them if they find them insecure.

I don't think it is limited to passkeys... I have always been forced to use the authentication chosen by the IT at work, it's not like I can come and say "You know what? Instead of your SSO coupled with your second factor app, I would like to use my own password manager with email and password".

replies(1): >>45117602 #
4. NoGravitas ◴[03 Sep 25 16:22 UTC] No.45117602{3}[source]▶
Work IT is different from services being offered to the public, though.
replies(1): >>45120885 #
5. palata ◴[03 Sep 25 22:05 UTC] No.45120885{4}[source]▶
The difference is the security requirements. Services that are fine today with you using just a username+password won't care at all if you use a passkey that is considered unsafe.
replies(1): >>45125617 #
6. NoGravitas ◴[04 Sep 25 10:22 UTC] No.45125617{5}[source]▶
Yes they will, because of risk aversion and cargo culting. They won't actually audit a passkey provider or have well-defined security criteria, but they will just require what everyone else requires.
replies(1): >>45132672 #
7. palata ◴[04 Sep 25 21:56 UTC] No.45132672{6}[source]▶
Hmm... why don't they already implement their own authenticator apps, if it's just risk aversion and cargo culting? Again it's totally possible and it already exists.

I currently, exclusively use my Yubikeys as passkeys, and it works everywhere where passkeys are available. So I don't personally see a problem.

What I see is that people complain because of some kind of disagreement that happened between some people on the Internet about the passkey implementation in KeepassXC. And nothing about that materialised.