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.
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.
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.
I fully agree, seems Linux is heading directly towards being a Windows Clone. So far all the windows crap can be easily avoided, but once these things are forced on me, it is bye bye Linux.
Already I use BSD on an older laptop probably 40% of the time. Linux on my main system is there due to a hardware device issue BSD still have a minor problem with it. But for me right now, Linux seems to be heading in a wrong direction.
KeepassXC implements passkeys in a respectful way. I don't see how this is "Windows crap". If they want to force attestation on passkey implementations, whether or not Linux supports it will not matter.
The part that matters is if people adopt the bait. If the bait doesn't get chomped on, the hook is ineffective. Actively encouraging passkey adoption is telling people to eat the bait.
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.
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!".
> 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.
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.
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.
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.
That's the key difference. If it mattered, they would make it part of the spec, not threaten a ban. That's even more concerning, there is a central group of people who get to decide who can and cannot use Passkeys.
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.
Attestation is not inherently incompatible with open source.
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, focusing on “open source” rather than e.g. “right to modify without being refused service”.
Well, it's stored in an encrypted way - in the encrypted password database. Much like a password, everyone already knows not to share a passkey. But also like a password, as the owner, sometimes I want to look at it!
It's an export format. The storage is always encrypted with the database key. And you can view the key directly anyway just like you can view passwords, and copy it from there.
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.
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 shouldn't do as I say.
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!
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.
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.
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.
What is the benefit of having full disk encryption pinned to a machine?
I fully agree, seems Linux is heading directly towards being a Windows Clone. So far all the windows crap can be easily avoided, but once these things are forced on me, it is bye bye Linux.
Already I use BSD on an older laptop probably 40% of the time. Linux on my main system is there due to a hardware device issue BSD still have a minor problem with it. But for me right now, Linux seems to be heading in a wrong direction.
KeepassXC implements passkeys in a respectful way. I don't see how this is "Windows crap". If they want to force attestation on passkey implementations, whether or not Linux supports it will not matter.
The part that matters is if people adopt the bait. If the bait doesn't get chomped on, the hook is ineffective. Actively encouraging passkey adoption is telling people to eat the bait.
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.
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/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!".
> 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.
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.
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.
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.
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.
> ask for
That's the key difference. If it mattered, they would make it part of the spec, not threaten a ban. That's even more concerning, there is a central group of people who get to decide who can and cannot use Passkeys.
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.
Attestation is not inherently incompatible with open source.
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, focusing on “open source” rather than e.g. “right to modify without being refused service”.
Well, it's stored in an encrypted way - in the encrypted password database. Much like a password, everyone already knows not to share a passkey. But also like a password, as the owner, sometimes I want to look at it!
Genuine question: why?
it's mine.
It's an export format. The storage is always encrypted with the database key. And you can view the key directly anyway just like you can view passwords, and copy it from there.
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.
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 shouldn't do as I say.
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!
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!
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.
That's interesting. How the actual passkeys will be stored with this approach?
No thanks, it stinks.