5 ms·

Credentials for Linux: Bringing Passkeys to the Linux Desktop

80 points by alfie42 9mo ago

digiown 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo ago
  [deleted]
notepad0x90 9mo ago
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.
- digiown 9mo ago
  Corporate interests HATE general purpose computing, and the freedom to run what you want. With that freedom, you can hurt their interests by blocking ads, stripping out spyware, or avoiding giving up your privacy, and they can't let you have that. It's a death by thousand cuts that's finally starting to come together: - Remote attestation like Play "integrity" - Hardware backed DRM like Widevine - No full access to filesystem on Android, and no access to filesystem at all on iOS - No ability to run your own programs at all on iOS without Apple's permission. - "Secure" boot on Android and iOS that do not allow running your own software Ever wondered why Windows 11 have a TPM requirement? No, it's not just planned obsolescence. If they get their way, user-owned computers running free software will never be usable again, and we'll lose the final escape hatch slowing down the enshittification of computers. The only hope we have is that they turn up the temperature a little too quickly that normies would catch on before it gets far enough.
  - hparadiz 9mo ago
    Windows 11 has tpm required to enforce full disk encryption that is pinned to a given machine. Linux would do well to do the same thing. It's possible but almost no one does it.
hexo 9mo ago
No thanks, it stinks.
shmerl 9mo ago
That's interesting. How the actual passkeys will be stored with this approach?
flumpcakes 9mo ago
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.
- ianburrell 9mo ago
  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.
hedora 9mo ago
Here’s a list of “transports” which (I think) are storage backends that manage the passkeys (preventing the user from controlling their own credentials). https://github.com/linux-credentials/libwebauthn?tab=readme-ov-file#Transports 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.)
chaz6 9mo ago
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.
harryelizabeth 9mo ago
[dead]

80 points by alfie42 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo ago
[deleted]

notepad0x90 9mo ago

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.

digiown 9mo ago
Corporate interests HATE general purpose computing, and the freedom to run what you want. With that freedom, you can hurt their interests by blocking ads, stripping out spyware, or avoiding giving up your privacy, and they can't let you have that. It's a death by thousand cuts that's finally starting to come together: - Remote attestation like Play "integrity" - Hardware backed DRM like Widevine - No full access to filesystem on Android, and no access to filesystem at all on iOS - No ability to run your own programs at all on iOS without Apple's permission. - "Secure" boot on Android and iOS that do not allow running your own software Ever wondered why Windows 11 have a TPM requirement? No, it's not just planned obsolescence. If they get their way, user-owned computers running free software will never be usable again, and we'll lose the final escape hatch slowing down the enshittification of computers. The only hope we have is that they turn up the temperature a little too quickly that normies would catch on before it gets far enough.
- hparadiz 9mo ago
  Windows 11 has tpm required to enforce full disk encryption that is pinned to a given machine. Linux would do well to do the same thing. It's possible but almost no one does it.

hexo 9mo ago

No thanks, it stinks.

shmerl 9mo ago

That's interesting. How the actual passkeys will be stored with this approach?

flumpcakes 9mo ago

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.

ianburrell 9mo ago
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.

hedora 9mo ago

Here’s a list of “transports” which (I think) are storage backends that manage the passkeys (preventing the user from controlling their own credentials). https://github.com/linux-credentials/libwebauthn?tab=readme-ov-file#Transports 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.)

chaz6 9mo ago

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.

harryelizabeth 9mo ago

[dead]