5 ms·

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

by digiown 8mo ago

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: https://github.com/keepassxreboot/keepassxc/issues/10406 https://github.com/keepassxreboot/keepassxc/issues/10406 https://github.com/keepassxreboot/keepassxc/issues/10407 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!".

cadamsdotcom 8mo ago
Agreed, unfortunately. Passwords are easy to understand, transparent and portable, and when used with good hygiene (always using password manager and generating unique & strong passwords for everything) there isn’t yet a strong case for anything else.
- doubled112 8mo ago
  I’m not happy with everything about passkeys either. I am fine with them as an additional method, but I would never use them as the only method. That said, I had a much easier time getting my kids onboard with a FIDO2 security key than I would have a password manager. Enter your email and touch this is easy to understand.
  - digiown 8mo ago
    One thing it enables is being the sole credential, as in, not needing usernames. It helps with faster logging in and is not prone to security issues caused by browser autofill. This also means sites can allow you to sign up without collecting any more info than registering a passkey, but of course they want to siphon all that data.
giancarlostoro 8mo ago
How do you even ban something like KeypassXC given that it is open source and any end user could basically edit KeypassXC and bypass a ban? Edit: Reading one of those issues it sounds like they want the keys stored in an encrypted way, is that too much to ask for? I dont care about viewing it but it shouldnt be stored in a plain easy to open JSON.
- digiown 8mo ago
  That's the thing, they can't yet. They are proposing an attestation scheme. I'm not sure the details are out yet, but the authenticator would presumably use one of the hardware security mechanisms (like a TPM bound key) to "certify" its own authenticity along with the challenge. This will effectively ban all open-source implementations, and end user freedom if widely adopted. Fortunately for us it seems like Apple isn't cooperating here for now, and without Apple signing on, it wouldn't get anywhere.
  - altairprime 8mo ago
    Attestation is not inherently incompatible with open source. Code signing keys are perfectly compatible with open source. You don’t ever commit them to the repo, if they’re even accessible to you at all (vs. in an HSM), and everyone can distinguish your official releases from forks and mods because yours are signed with your key. Attestation is incompatible with having the authority conferred upon upstream automatically inherited by all forks thereof. If you want your fork to have the same authority as upstream, you have to apply for that authority to be recognized and make your case that it deserves that. This is the problem with attestation: that it reintroduces human reputation authorities into the Wild West of computing. If you’re going to argue successfully against attestation, you’ll need to focus on the actual problem rather than the distraction of source code licensing. The same attestation would be necessary whether the app you’re modding is closed source, open source, or a PICO-8 cartridge image: when attestation is in play, everyone knows you’re running a modded version, and they may choose to deny you service over that. That’s the problem attestation poses, and why arguments against passkeys fail so spectacularly to gain traction, by focusing on “open source” (irrelevant) rather than e.g. “right to be modify without being refused service”.
signal11 8mo ago
Shafting open source projects that implement your spec is not okay, and is terrible optics. Tech journalists should ask the FIDO Alliance if they’re just Google+Apple+Microsoft in a trenchcoat. Definitely not very open!
- digiown 8mo ago
  I do get that there are use cases for actual hardware bound keys for enterprise settings. But having non-exportable credentials (effectively non-ownable) is not acceptable in a consumer setting. This is a thinly veiled attempt at strengthening platform lock-in. Look, the spec says you can't export the keys to a file! Too bad, go re-register your 120 websites if you want to stop using iCloud/Google!
  - Groxx 8mo ago
    Particularly because "you must use only an approved passkey manager" is fairly easily solved by MDM, which is already widespread. It's DRM, and it will go down exactly the same anti-user and anti-competitive route as every other DRM. Fight it with fervor.
  - signal11 8mo ago
    Last I checked, they were working on interop so you can move your keys from one provider to another without creating CSV files or equivalent[1]. However from my PoV — if the user or an open source project wants to create CSV files, they should be free to do so. That’s part of putting the user in control. For me, KeePass XC is the canary in the coal mine that helps me figure out what FIDO’s priorities are. I don’t have a problem with crypto around passkeys. They’re great. The non-functionals though (including shipping passkeys without good import/export) are a bit of a mess. [1] https://fidoalliance.org/fido-alliance-publishes-new-specifications-to-promote-user-choice-and-enhanced-ux-for-passkeys/ https://fidoalliance.org/fido-alliance-publishes-new-specifi...
politelemon 8mo ago
> It appears that the spec authors do not consider the keys to be owned by the user at all. This was my impression, and it explains why the original announcement involved companies that would benefit the most from keeping their users on a leash.
AndrewDucker 8mo ago
They don't consider the key to belong to the user. The key is a token generated by the site to allow it to identify a user. In order for them to do perfectly so they do not want users to be able to tamper with them, leak them, or do anything which might violate their assumptions about the key.
- mzajc 8mo ago
  No, the private key is generated and stored client-side, and never sent to the server. Even if that wasn't the case, how I store my credentials is none of the websites' business, and my own hardware should do as I say.
FreakLegion 8mo ago
I'm replying to this post, but your other posts throughout the thread have similar misunderstandings. User presence tests are an anti-malware feature. The point is that a machine can be compromised without letting bad guys log into your accounts willy-nilly. Is it a super useful feature? No. The bad guys can steal the tokens for accounts you're actively logged into anyway. But that's why the test exists. The whole back and forth about plaintext keys is pretty much people talking past each other. Approximately nobody thinks users shouldn't be able to access their keys in the general case. FIDO just wasn't originally designed for the general case (see Operation Aurora). Now it's playing catch-up. KeePassXC is not "being threatened with being banned via attestation". Attestation requirements are set by the service you're logging into, and KeePassXC is already locked out where those requirements exist (pretty much exclusive to a small number of corporate and government orgs). A random guy from Okta is not threatening to ban KeePassXC.
- digiown 8mo ago
  > Approximately nobody thinks users shouldn't be able to access their keys in the general case Citation needed. To me it seems to be the quiet part that they aren't saying out loud. If it's just a consequence of the spec being unfinished, then they shouldn't threaten to ban KeepassXC for this. The purpose of a system is what it does, and commercial passkey implementations lock users out of their credentials and uses it to strengthen vendor lock-in. > Is it a super useful feature? No It's security theater and a way for websites to annoy users unnecessarily. > KeePassXC is not "being threatened with being banned via attestation". https://github.com/keepassxreboot/keepassxc/issues/10406#issuecomment-1994313373 https://github.com/keepassxreboot/keepassxc/issues/10406#iss... It's a thinly veiled threat. Making a certification process and refusing to certify KeepassXC is exactly the same as banning it.
  - FreakLegion 8mo ago
    Let's be specific. Who is "they"? Who do you think is threatening to ban KeePassXC? A mid-level Okta employee? The whole FIDO Alliance? Brother, there's no conspiracy here. Attestation requires a trusted third party, same as TLS. You know how you can generate self-signed certificates, but your browser and other tools don't trust them? Attestation is like that. What you keep calling a "ban" is a trivial operational consequence of this. Individual services still get to decide whether attestation is even required, and in the consumer space you aren't going to see it much.
zamalek 8mo ago
The problem with plain text access (on hardware devices) is that it allows cloning. That is more hostile to users, but it is a stronger security posture. You're supposed to have a backup device somewhere secure, but of course there are many websites that didn't get the memo and only allow a single device.
- veeti 8mo ago
  That's a nice thought but how does it work in practice? Every time I sign up for a new service I have to dig up my "backup device" from the safe just to enroll it? Google Authenticator used to be this way: no backup and restore, as if I'm going to spend a day setting up dozens of TOTP codes again and again every time I change phones. Thankfully, sanity has prevailed since then.
deleted 8mo ago
[deleted]

by digiown 8mo ago

cadamsdotcom 8mo ago

Agreed, unfortunately. Passwords are easy to understand, transparent and portable, and when used with good hygiene (always using password manager and generating unique & strong passwords for everything) there isn’t yet a strong case for anything else.

doubled112 8mo ago
I’m not happy with everything about passkeys either. I am fine with them as an additional method, but I would never use them as the only method. That said, I had a much easier time getting my kids onboard with a FIDO2 security key than I would have a password manager. Enter your email and touch this is easy to understand.
- digiown 8mo ago
  One thing it enables is being the sole credential, as in, not needing usernames. It helps with faster logging in and is not prone to security issues caused by browser autofill. This also means sites can allow you to sign up without collecting any more info than registering a passkey, but of course they want to siphon all that data.

giancarlostoro 8mo ago

How do you even ban something like KeypassXC given that it is open source and any end user could basically edit KeypassXC and bypass a ban? Edit: Reading one of those issues it sounds like they want the keys stored in an encrypted way, is that too much to ask for? I dont care about viewing it but it shouldnt be stored in a plain easy to open JSON.

digiown 8mo ago
That's the thing, they can't yet. They are proposing an attestation scheme. I'm not sure the details are out yet, but the authenticator would presumably use one of the hardware security mechanisms (like a TPM bound key) to "certify" its own authenticity along with the challenge. This will effectively ban all open-source implementations, and end user freedom if widely adopted. Fortunately for us it seems like Apple isn't cooperating here for now, and without Apple signing on, it wouldn't get anywhere.
- altairprime 8mo ago
  Attestation is not inherently incompatible with open source. Code signing keys are perfectly compatible with open source. You don’t ever commit them to the repo, if they’re even accessible to you at all (vs. in an HSM), and everyone can distinguish your official releases from forks and mods because yours are signed with your key. Attestation is incompatible with having the authority conferred upon upstream automatically inherited by all forks thereof. If you want your fork to have the same authority as upstream, you have to apply for that authority to be recognized and make your case that it deserves that. This is the problem with attestation: that it reintroduces human reputation authorities into the Wild West of computing. If you’re going to argue successfully against attestation, you’ll need to focus on the actual problem rather than the distraction of source code licensing. The same attestation would be necessary whether the app you’re modding is closed source, open source, or a PICO-8 cartridge image: when attestation is in play, everyone knows you’re running a modded version, and they may choose to deny you service over that. That’s the problem attestation poses, and why arguments against passkeys fail so spectacularly to gain traction, by focusing on “open source” (irrelevant) rather than e.g. “right to be modify without being refused service”.

signal11 8mo ago

Shafting open source projects that implement your spec is not okay, and is terrible optics. Tech journalists should ask the FIDO Alliance if they’re just Google+Apple+Microsoft in a trenchcoat. Definitely not very open!

digiown 8mo ago
I do get that there are use cases for actual hardware bound keys for enterprise settings. But having non-exportable credentials (effectively non-ownable) is not acceptable in a consumer setting. This is a thinly veiled attempt at strengthening platform lock-in. Look, the spec says you can't export the keys to a file! Too bad, go re-register your 120 websites if you want to stop using iCloud/Google!
- Groxx 8mo ago
  Particularly because "you must use only an approved passkey manager" is fairly easily solved by MDM, which is already widespread. It's DRM, and it will go down exactly the same anti-user and anti-competitive route as every other DRM. Fight it with fervor.
- signal11 8mo ago
  Last I checked, they were working on interop so you can move your keys from one provider to another without creating CSV files or equivalent[1]. However from my PoV — if the user or an open source project wants to create CSV files, they should be free to do so. That’s part of putting the user in control. For me, KeePass XC is the canary in the coal mine that helps me figure out what FIDO’s priorities are. I don’t have a problem with crypto around passkeys. They’re great. The non-functionals though (including shipping passkeys without good import/export) are a bit of a mess. [1] https://fidoalliance.org/fido-alliance-publishes-new-specifications-to-promote-user-choice-and-enhanced-ux-for-passkeys/ https://fidoalliance.org/fido-alliance-publishes-new-specifi...

politelemon 8mo ago

> It appears that the spec authors do not consider the keys to be owned by the user at all. This was my impression, and it explains why the original announcement involved companies that would benefit the most from keeping their users on a leash.

AndrewDucker 8mo ago

They don't consider the key to belong to the user. The key is a token generated by the site to allow it to identify a user. In order for them to do perfectly so they do not want users to be able to tamper with them, leak them, or do anything which might violate their assumptions about the key.

mzajc 8mo ago
No, the private key is generated and stored client-side, and never sent to the server. Even if that wasn't the case, how I store my credentials is none of the websites' business, and my own hardware should do as I say.

FreakLegion 8mo ago

I'm replying to this post, but your other posts throughout the thread have similar misunderstandings. User presence tests are an anti-malware feature. The point is that a machine can be compromised without letting bad guys log into your accounts willy-nilly. Is it a super useful feature? No. The bad guys can steal the tokens for accounts you're actively logged into anyway. But that's why the test exists. The whole back and forth about plaintext keys is pretty much people talking past each other. Approximately nobody thinks users shouldn't be able to access their keys in the general case. FIDO just wasn't originally designed for the general case (see Operation Aurora). Now it's playing catch-up. KeePassXC is not "being threatened with being banned via attestation". Attestation requirements are set by the service you're logging into, and KeePassXC is already locked out where those requirements exist (pretty much exclusive to a small number of corporate and government orgs). A random guy from Okta is not threatening to ban KeePassXC.

digiown 8mo ago
> Approximately nobody thinks users shouldn't be able to access their keys in the general case Citation needed. To me it seems to be the quiet part that they aren't saying out loud. If it's just a consequence of the spec being unfinished, then they shouldn't threaten to ban KeepassXC for this. The purpose of a system is what it does, and commercial passkey implementations lock users out of their credentials and uses it to strengthen vendor lock-in. > Is it a super useful feature? No It's security theater and a way for websites to annoy users unnecessarily. > KeePassXC is not "being threatened with being banned via attestation". https://github.com/keepassxreboot/keepassxc/issues/10406#issuecomment-1994313373 https://github.com/keepassxreboot/keepassxc/issues/10406#iss... It's a thinly veiled threat. Making a certification process and refusing to certify KeepassXC is exactly the same as banning it.
- FreakLegion 8mo ago
  Let's be specific. Who is "they"? Who do you think is threatening to ban KeePassXC? A mid-level Okta employee? The whole FIDO Alliance? Brother, there's no conspiracy here. Attestation requires a trusted third party, same as TLS. You know how you can generate self-signed certificates, but your browser and other tools don't trust them? Attestation is like that. What you keep calling a "ban" is a trivial operational consequence of this. Individual services still get to decide whether attestation is even required, and in the consumer space you aren't going to see it much.

zamalek 8mo ago

The problem with plain text access (on hardware devices) is that it allows cloning. That is more hostile to users, but it is a stronger security posture. You're supposed to have a backup device somewhere secure, but of course there are many websites that didn't get the memo and only allow a single device.

veeti 8mo ago
That's a nice thought but how does it work in practice? Every time I sign up for a new service I have to dig up my "backup device" from the safe just to enroll it? Google Authenticator used to be this way: no backup and restore, as if I'm going to spend a day setting up dozens of TOTP codes again and again every time I change phones. Thankfully, sanity has prevailed since then.

deleted 8mo ago

[deleted]