Passkey/webauthn is a cool tech, and I'd really like to use it everywhere, but I find the anti-user attitudes of the spec authors concerning. The spec contains provisions about "user verification" (the software must force user interaction) and not allowing the user to access the plaintext keys. It appears that the spec authors do not consider the keys to be owned by the user at all.
KeepassXC implements passkey support, but they do not implement these anti-user features. As a result, they are being threatened with being banned via attestation:
Screw these "You'll own nothing and be happy" people. I'll own all my keys no matter what. The software I run on my device should never betray me to signal things like "this passkey is allowed to be backed up!".
I just wish more people would protest this instead of things like secure boot.
Password managers and/or operating systems can manage private keys just fine. websites shouldn't be concerned with how the keys are managed, or be able to make demands on how users store credentials, or know device details for users.
One thing I dislike even with systems like FIDO2 is that the websites/apps can block list your FIDO key's vendors. Similar trends suck. Passkeys are just one iteration in a long line of systems designed with corporate interests in mind.
The system validating the authentication needs only to verify that the credentials are correct. If users want to use TPMs, HSMs,etc.. or none at all, that's up to them. And no information, other than what is strictly required to verify the credential should be transmitted over the network. a signature of challenge data from the app should be sufficient. the user's public key shouldn't be signed at all by hardware, a trusted 3rd party,etc.. the registration process should take care of establishing public key trust to the authenticator/app. The whole thing feels insidious.
> The system validating the authentication needs only to verify that the credentials are correct. If users want to use TPMs, HSMs,etc.. or none at all, that's up to them.
That's not up to the user in a corporate environment. If you use company supplied hardware keys for FIDO2 you don't want users using some software emulator on their phone because they think it's easier.
Websites blocking FIDO vendors is nothing new. In corporate environments this may be necessary. Imagine a 2-tiered environment where generally all vendors are allowed (no blocks) for accessing tier-1 information, but to access tier-2 you need a special vendor. That is not uncommon.
By the way, SAML has similar authentication restrictions, so this is not something FIDO came up with.
I'm a big fan of passkeys, but they are currently harder to manage/reason about than passwords (even autogenerated ones stored in a password manager).
My web browser wants to own the passkeys, my OS wants to own the passkeys, I have to deny them before I can get to my hardware key. Some providers will sync passkeys amongst devices, which at some point seemed to be against the spec.
It's all rather confusing. I wish there was a straight forward best practise that can be followed without the niggling worry that you're doing it wrong, or that you might get locked out of services.
Storing passkeys in password managers is the best option. It isn't as secure as hardware tokens, but it solves the problem of managing multiple keys and losing the tokens.
Passkeys are better passwords since not vulnerable to phishing, and it makes sense to store better passwords in password manager.
Here’s a list of “transports” which (I think) are storage backends that manage the passkeys (preventing the user from controlling their own credentials).
Are there any passkey hardware tokens the private key is effectively irretrievable? That is why up to now FIDO U2F has been my preferred additional factor. The down side is that you have to register multiple tokens for each authentication service in case one is lost or damaged. I miss the days of openid when I could use my own idp with any service, but the walls quickly went up when the big players wanted to control the ecosystem.
12 comments
[ 2.6 ms ] story [ 30.9 ms ] threadKeepassXC implements passkey support, but they do not implement these anti-user features. As a result, they are being threatened with being banned via attestation:
https://github.com/keepassxreboot/keepassxc/issues/10406
https://github.com/keepassxreboot/keepassxc/issues/10407
Screw these "You'll own nothing and be happy" people. I'll own all my keys no matter what. The software I run on my device should never betray me to signal things like "this passkey is allowed to be backed up!".
Password managers and/or operating systems can manage private keys just fine. websites shouldn't be concerned with how the keys are managed, or be able to make demands on how users store credentials, or know device details for users.
One thing I dislike even with systems like FIDO2 is that the websites/apps can block list your FIDO key's vendors. Similar trends suck. Passkeys are just one iteration in a long line of systems designed with corporate interests in mind.
The system validating the authentication needs only to verify that the credentials are correct. If users want to use TPMs, HSMs,etc.. or none at all, that's up to them. And no information, other than what is strictly required to verify the credential should be transmitted over the network. a signature of challenge data from the app should be sufficient. the user's public key shouldn't be signed at all by hardware, a trusted 3rd party,etc.. the registration process should take care of establishing public key trust to the authenticator/app. The whole thing feels insidious.
That's not up to the user in a corporate environment. If you use company supplied hardware keys for FIDO2 you don't want users using some software emulator on their phone because they think it's easier.
By the way, SAML has similar authentication restrictions, so this is not something FIDO came up with.
My web browser wants to own the passkeys, my OS wants to own the passkeys, I have to deny them before I can get to my hardware key. Some providers will sync passkeys amongst devices, which at some point seemed to be against the spec.
It's all rather confusing. I wish there was a straight forward best practise that can be followed without the niggling worry that you're doing it wrong, or that you might get locked out of services.
Passkeys are better passwords since not vulnerable to phishing, and it makes sense to store better passwords in password manager.
https://github.com/linux-credentials/libwebauthn?tab=readme-...
Anyone have any idea how hard it is to add “text file” or (god forbid) “TPM with user supplied keys” to the list?
(The latter would let you backup your keys securely, and then recover them by using the keys, which you backed up elsewhere.)