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.
When you have Apple managing your keychain, your passwords stored in that, your passkeys stored in that, them filling in your MFA info by reading your email and SMS on every device, supplying your primary email account and all your throwaway addresses, and possibly trying to tie you into their OAuth or whatever for a third party, you are fucked if something goes trivially wrong.
Welcome to being a human being, where you need dozens of different accounts and passwords and passkeys and authenticators to live in modern society.
Apple passwords just work. They integrate nicely with most websites where I can authenticate using biometrics instead of copy-pasting and leaving my credentials on my clipboard.
And let's be real here, no one else in the industry comes even close to the amount of investment, research, and maintenance of security platforms than Apple. I would not bet against Apple's security failing.
Everything is a tradeoff between convinience and security. I think Apple's password manager is the perfect middleground. I let it generate different passwords for every site, store my passkeys etc.
No one has the time to fully optimize their security footprint. No one. And if you do you're either A) working in a sensitive area that requires it for your job or B) being targeted by state-level threat actors or C) lying. Anything beyond a password manager + 2fa is severe overkill for anyone else.
The way apple implemented things is great, no argument there. Others need to tech note. But the same thing could have been implemented without requiring device/iOS lock-in. I don't care to malign apple, but alternatives need to work as well, and as smoothly as apple passwords and passkeys, without the corporate malice.
> I would not bet against Apple's security failing.
I wouldn't either, but now the same tech is going to be used by everyone, and Apple's goal of vendor-lockin succeeds. Their security isn't in question, their malicious and anti-competitive practices are. They are secure, and it works well. You're also tied into their ecosystem, and devices. they collect information that isn't necessary for their products to work well, and securely. You can't fault them for being greedy, they're not particularly worse in that regard, but industry needs to standardize better alternatives that work well, without the whole "you have to trust apple, and it's okay that they lock in people to their ecosystem" angle.
If authentication requires the website/app to demand anything that can only be obtained on an apple device, that is a user hostile and anti-competitive feature. What confounds me is that Apple has a strong user-base, doing this the right way doesn't cost them much. Making a user friendly authentication protocol that works without attestation and hardware-lockin doesn't hurt them. They don't need to play dirty and lockin users, their fanbase is already strong. They're just being greedy for that extra 0.001 increase.
If you have a password manager, 2FA is pointless anyway. Password manager already serves as two factors: possession of the database and the secret to decrypt it. 2FA is a mitigation against people getting pwned by reusing passwords or using bad passwords. Neither of which applies if you use a password manager. You can use the TOTP feature in KeepassXC for when it is useful.
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.
Don't forget an entire new category of computing, AI, which is teetering on the edge of requiring processors from one manufacturer, which in turn requires gigabytes of closed-source runtime. Today, you can do functionally more with a computer with an nVidia chip, driven by their binary blobs, than with any other hardware - even though the application software is usually Free. It's a dangerous situation. We are so used to general purpose compute substrate being "free software friendly", but this amounts to a new type of CPU that categorically requires a closed-source OS to be useful.
You wouldn't have a free society for long if the general purpose computers are taken away. The government controls corporations which controls your computers, and with an order all of your devices will be turned against you like the telescreens in 1984. We're already scarily close to that reality.
Why are y'all so scared only when it's the government using the companies to influence people. The companies do it themselves already and in a much more insidious way than any government likely will.
You are already being fed propaganda and having your interactions controlled and monitored in order for the people in power to gain more power and stay in power indefinitely. This is already almost 1984. It's just not politicians in power, it's capitalists.
How is that better? At least we can, in theory, elect different politicians. With capitalists, that doesn't exist even in theory.
Is this question being asked in a way that we actually get to choose? Because the obvious choice is general purpose computing plus a free society. But rather it feels that what is being picked for us is copyright, and only copyright.
But really, even picking the freedom and liberty options, copyright could survive just fine as a thing that applies to corporations and other business entities. Individuals could then be left with a choice whether to support their creators or not, which would be a better bargain for many creators without the middlemen taking hefty cuts.
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.
Linux should replicate Microsoft's feature where they back up your "full disk encryption" keys to your cloud account, completely unencrypted, and share them with the cops.
They really should (no joke). That's how recovery works when you manage lots of devices. And I wouldn't be surprised if they can do that with Linux already via Intune.
Full disk-encryption doesn't mean your encryption key never leaves the device. Matter of fact, there is no point in FDE if the key is readily accessible pre-boot on the device. And no mature key management system relies on users remembering credentials as the end-all-be-all. Even login credentials have recovery mechanisms. With FDE, that is the recovery mechanism.
It helps with locking out disks after a device is lost/stolen. it also helps when the hardware is fried and you have important data that needs recovery. Imagine that but you have 100k devices to manage that way. Are you going to rely on a revolving-door of 100k+ employees to manage that credential? And I'm sure it's stored on disk encrypted in their DB, but eventually the unencrypted credential is needed. Block-ciphers ultimately need the plain-text secret provided to them to function, regardless of what complex systems you use, the ciphers need the same deterministic secret.
Ultimately this isn't any worse than being able to go to their website and have a recovery link sent to your email, except instead of the whole send email part, you have to be an authorized admin or owner in their portal, and you just get it from there. Pre-boot, there is no networking or internet, even things like correct time information can't be guaranteed, for more complex systems.
LUKS supports multiple decryption methods so you could for example add one with a really long string or a yubikey as a backup. Most folks replying here aren't encrypting anything at all.
You can print recovery codes. Just chuck them in your safe.
Cryptography is only safe against someone who doesn't come and beat the password out of you if they want it. In my case, only my laptop is encrypted so if I lose it when I'm out it's useless.
The benefit is to not type encryption password on every boot. TPM stores the encryption key and Secure Boot ensures that the system is not tampered.
That said, I think that it's better to use alternative approach. Use unencrypted signed system partition which presents login screen. After user typed their username and password, only user home gets decrypted. This scheme does not require TPM and only uses secure boot to ensure that system partition has not been altered. I think that macOS uses similar approach.
It is quite hard to do this safely on typical Linux systems, since there is a substantial amount of writable system data (e.g. syslog, /etc, /var). If unencrypted they will leak data, and if encrypted there is little difference from just encrypting the root.
A typical linux system will have everything in one partition and even if you do like to split up the system (for historical re-enactment?) it wouldn't matter as you'd be encrypting the whole disk anyway.
This whole assumption that TPM is a secure way to store things is ridiculously faulty. It's an interceptable i2c bus, and there's multiple tools available since 0.9 that can recover keys from both cold RAM boot and from interception of the i2c bus.
If your laptop gets stolen, the thief also has your keys and can also decrypt the hard drive, which the TPM storage initially was supposed to have been invented for to actively prevent.
> 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.
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.
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.
Here’s a list of “transports” which (I think) are storage backends that manage the passkeys (preventing the user from controlling their own credentials).
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.
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.
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.
> 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".
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.
The "they" is any corporation that has an interest in the user not controlling their system, and whom this technology caters to. This sea has plenty of fish already. Streaming services serving Hollywood content, banks, dating apps...
Lastly I even faced another one. Something as simple as a gym token wants GMS, attestation and GPS positioning because it treats its users as liars prima facie. That's the new norm this attestation enables. No conspiracy needed, simple business interest and greed to juice "customers" to the last penny drives you there.
You're on a tangent from the discussion you're replying to. Individual services get to decide requirements for their users, but that's not at all the same as "banning" KeePassXC from the entire ecosystem.
Like, there are lots of services that require SMS or email link MFA. I guess KeePassXC is just banned from everything, then?
To repeat, the GitHub issue digiown linked is not a threat to ban KeePassXC. A random guy from Okta doesn't have that power. Okta itself doesn't have that power or want to have that power. The GitHub issue is simply a description of what attestation is.
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!
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.
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.
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. 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”.
> right to be different without being refused service
You can check my comment history to see the arguments I have against attestation. That's exactly what I argue. It's not an open source problem, it's a user freedom problem, and this is exactly why corporate interests like "open source", but not "free software". Open source is freedom-agnostic: you can use it to hurt users just fine. The current iterations of remote attestation is especially egregious, because most of it is the government itself or an entity the government forces you to deal with (banks).
In general I believe remote attestation is actually fine, so long as it does not transcend ownership boundaries. A company can use it to ensure its own colo servers aren't tampered with, for example. But an external authority shouldn't be able to exert control over something I own. In particular there should be no expectation that my device is "trustworthy" in any way at all. Anything else ends privacy and freedom as we know it.
> this will effectively ban all open-source implementations
This is the only point where I differ: it will effectively ban most implementations, with no regard for whether they’re open source, closed source, or private. 1Password could be open-sourced tomorrow and continue being an approved implementation, no sweat, because they can be trusted not to disguise and release “export your passkeys as plaintext at rest” functionality — but in today’s market, there are certainly a thousand implementations (whether source or not) that died on the vine, whose sole purpose would have been to circumvent that one restriction, far more than there are implementations that are willing to genuinely try to uphold it.
Glad someone else is fighting for repurposeability — but there is no universal answer for how to balance privacy, freedom, and security. It’s something people have to decide for themselves, and just as my phone has an “highest security, lower convenience” mode for certain scenarios, so too I wish it had a “no security, total modifiability” mode for other scenarios. (Even if that denied me app store access, and I would demand that it wipe pre-existing passkeys from the HSM when I enabled freedom mode, or else it’s just an uncontrolled attack vector!)
It was perhaps not phrased that well. I meant that it would prevent passkeys from being used on user-controlled systems at all, since there wouldn't be a way for a passkey implementation to hide the attestation key from the user if the user can perform arbitrary modifications to the operating system. It will end up exactly like one of these DRM schemes, where you can't watch more than 720p videos on Linux.
Remote attestation in general is a backdoor to software freedom and ownership bestowed on you by free software, in the same way that tivoization is. Tivoization prevents you from running a modified version of the software on the same hardware, while attestation discriminates against you for running a modified version.
I do agree we should have repurposeability, but that's mostly independent of this attestation topic, IMO. I also think the tradeoff between security/privacy and freedom is greatly overblown. There is some, but giving the user an adb root shell or ssh server with key will not significantly decrease security of the user on Android. (It might reduce the security of the apps against the user, but it shouldn't be there in the first place). I'd be fine with not having app store access if it isn't mandatory for daily life, but that's not the case in our world.
> they want the keys stored in an encrypted way, is that too much to ask for
Well, they are encrypted but the issue is talking about exports. The maintainer of KeepassXC already mentions the issue with that: portability. A backup of such sensitive data (a password manager) is going to be stored somewhere secure (to the user) already. Why would you encrypt the contents and add another layer of complexity that other tools may not be able to handle? I want to be able to rely on those backups in the future and copy paste them around manually if needed. It's user choice, put simply.
A specification committee should never be deciding what a user does with their data, period. The security maximalist is always going to advocate for the most secure thing but most of the time that's not practical or friendly to humans.
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!
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.
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.
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.
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.
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 should do as I say.
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.
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.
Oh that's not even the worst of the stupid shit.
When you have Apple managing your keychain, your passwords stored in that, your passkeys stored in that, them filling in your MFA info by reading your email and SMS on every device, supplying your primary email account and all your throwaway addresses, and possibly trying to tie you into their OAuth or whatever for a third party, you are fucked if something goes trivially wrong.
Okay, a
Hi, I'm one of those people.
Welcome to being a human being, where you need dozens of different accounts and passwords and passkeys and authenticators to live in modern society.
Apple passwords just work. They integrate nicely with most websites where I can authenticate using biometrics instead of copy-pasting and leaving my credentials on my clipboard.
And let's be real here, no one else in the industry comes even close to the amount of investment, research, and maintenance of security platforms than Apple. I would not bet against Apple's security failing.
Everything is a tradeoff between convinience and security. I think Apple's password manager is the perfect middleground. I let it generate different passwords for every site, store my passkeys etc.
No one has the time to fully optimize their security footprint. No one. And if you do you're either A) working in a sensitive area that requires it for your job or B) being targeted by state-level threat actors or C) lying. Anything beyond a password manager + 2fa is severe overkill for anyone else.
The way apple implemented things is great, no argument there. Others need to tech note. But the same thing could have been implemented without requiring device/iOS lock-in. I don't care to malign apple, but alternatives need to work as well, and as smoothly as apple passwords and passkeys, without the corporate malice.
> I would not bet against Apple's security failing.
I wouldn't either, but now the same tech is going to be used by everyone, and Apple's goal of vendor-lockin succeeds. Their security isn't in question, their malicious and anti-competitive practices are. They are secure, and it works well. You're also tied into their ecosystem, and devices. they collect information that isn't necessary for their products to work well, and securely. You can't fault them for being greedy, they're not particularly worse in that regard, but industry needs to standardize better alternatives that work well, without the whole "you have to trust apple, and it's okay that they lock in people to their ecosystem" angle.
If authentication requires the website/app to demand anything that can only be obtained on an apple device, that is a user hostile and anti-competitive feature. What confounds me is that Apple has a strong user-base, doing this the right way doesn't cost them much. Making a user friendly authentication protocol that works without attestation and hardware-lockin doesn't hurt them. They don't need to play dirty and lockin users, their fanbase is already strong. They're just being greedy for that extra 0.001 increase.
If you have a password manager, 2FA is pointless anyway. Password manager already serves as two factors: possession of the database and the secret to decrypt it. 2FA is a mitigation against people getting pwned by reusing passwords or using bad passwords. Neither of which applies if you use a password manager. You can use the TOTP feature in KeepassXC for when it is useful.
> 2FA is a mitigation against people getting pwned by reusing passwords or using
Stolen/lost password hashes or some AI based programmer that dumped passwords in plaintext somewhere in a database.
If 2FA is proper even trivial passwords are fine.
Saw a post here last month about an iCloud user losing their entire life, so do with that what you will.
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.
Don't forget an entire new category of computing, AI, which is teetering on the edge of requiring processors from one manufacturer, which in turn requires gigabytes of closed-source runtime. Today, you can do functionally more with a computer with an nVidia chip, driven by their binary blobs, than with any other hardware - even though the application software is usually Free. It's a dangerous situation. We are so used to general purpose compute substrate being "free software friendly", but this amounts to a new type of CPU that categorically requires a closed-source OS to be useful.
General purpose computers, copyright, a free society. Pick two.
You wouldn't have a free society for long if the general purpose computers are taken away. The government controls corporations which controls your computers, and with an order all of your devices will be turned against you like the telescreens in 1984. We're already scarily close to that reality.
Why are y'all so scared only when it's the government using the companies to influence people. The companies do it themselves already and in a much more insidious way than any government likely will.
You are already being fed propaganda and having your interactions controlled and monitored in order for the people in power to gain more power and stay in power indefinitely. This is already almost 1984. It's just not politicians in power, it's capitalists.
How is that better? At least we can, in theory, elect different politicians. With capitalists, that doesn't exist even in theory.
Is this supposed to be a difficult choice?
Is this question being asked in a way that we actually get to choose? Because the obvious choice is general purpose computing plus a free society. But rather it feels that what is being picked for us is copyright, and only copyright.
But really, even picking the freedom and liberty options, copyright could survive just fine as a thing that applies to corporations and other business entities. Individuals could then be left with a choice whether to support their creators or not, which would be a better bargain for many creators without the middlemen taking hefty cuts.
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.
This sounds like a great way to lose data when the machine dies unexpectedly.
Linux should replicate Microsoft's feature where they back up your "full disk encryption" keys to your cloud account, completely unencrypted, and share them with the cops.
They really should (no joke). That's how recovery works when you manage lots of devices. And I wouldn't be surprised if they can do that with Linux already via Intune.
Full disk-encryption doesn't mean your encryption key never leaves the device. Matter of fact, there is no point in FDE if the key is readily accessible pre-boot on the device. And no mature key management system relies on users remembering credentials as the end-all-be-all. Even login credentials have recovery mechanisms. With FDE, that is the recovery mechanism.
It helps with locking out disks after a device is lost/stolen. it also helps when the hardware is fried and you have important data that needs recovery. Imagine that but you have 100k devices to manage that way. Are you going to rely on a revolving-door of 100k+ employees to manage that credential? And I'm sure it's stored on disk encrypted in their DB, but eventually the unencrypted credential is needed. Block-ciphers ultimately need the plain-text secret provided to them to function, regardless of what complex systems you use, the ciphers need the same deterministic secret.
Ultimately this isn't any worse than being able to go to their website and have a recovery link sent to your email, except instead of the whole send email part, you have to be an authorized admin or owner in their portal, and you just get it from there. Pre-boot, there is no networking or internet, even things like correct time information can't be guaranteed, for more complex systems.
LUKS supports multiple decryption methods so you could for example add one with a really long string or a yubikey as a backup. Most folks replying here aren't encrypting anything at all.
You can print recovery codes. Just chuck them in your safe.
Cryptography is only safe against someone who doesn't come and beat the password out of you if they want it. In my case, only my laptop is encrypted so if I lose it when I'm out it's useless.
What is the benefit of having full disk encryption pinned to a machine?
The benefit is to not type encryption password on every boot. TPM stores the encryption key and Secure Boot ensures that the system is not tampered.
That said, I think that it's better to use alternative approach. Use unencrypted signed system partition which presents login screen. After user typed their username and password, only user home gets decrypted. This scheme does not require TPM and only uses secure boot to ensure that system partition has not been altered. I think that macOS uses similar approach.
It is quite hard to do this safely on typical Linux systems, since there is a substantial amount of writable system data (e.g. syslog, /etc, /var). If unencrypted they will leak data, and if encrypted there is little difference from just encrypting the root.
You encrypt the entire partition with LUKS. Not individual folders and files.
A typical linux system will have everything in one partition and even if you do like to split up the system (for historical re-enactment?) it wouldn't matter as you'd be encrypting the whole disk anyway.
Kinda like how I have it set up in linux except the system partition is the uki and the user password is LUKS2 passphrase
This whole assumption that TPM is a secure way to store things is ridiculously faulty. It's an interceptable i2c bus, and there's multiple tools available since 0.9 that can recover keys from both cold RAM boot and from interception of the i2c bus.
If your laptop gets stolen, the thief also has your keys and can also decrypt the hard drive, which the TPM storage initially was supposed to have been invented for to actively prevent.
Anti theft
> 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.
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.
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.
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-...
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.)
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.
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.
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.
> 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#iss...
It's a thinly veiled threat. Making a certification process and refusing to certify KeepassXC is exactly the same as banning it.
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.
The "they" is any corporation that has an interest in the user not controlling their system, and whom this technology caters to. This sea has plenty of fish already. Streaming services serving Hollywood content, banks, dating apps...
Lastly I even faced another one. Something as simple as a gym token wants GMS, attestation and GPS positioning because it treats its users as liars prima facie. That's the new norm this attestation enables. No conspiracy needed, simple business interest and greed to juice "customers" to the last penny drives you there.
You're on a tangent from the discussion you're replying to. Individual services get to decide requirements for their users, but that's not at all the same as "banning" KeePassXC from the entire ecosystem.
Like, there are lots of services that require SMS or email link MFA. I guess KeePassXC is just banned from everything, then?
To repeat, the GitHub issue digiown linked is not a threat to ban KeePassXC. A random guy from Okta doesn't have that power. Okta itself doesn't have that power or want to have that power. The GitHub issue is simply a description of what attestation is.
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.
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-specifi...
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.
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. 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”.
> right to be different without being refused service
You can check my comment history to see the arguments I have against attestation. That's exactly what I argue. It's not an open source problem, it's a user freedom problem, and this is exactly why corporate interests like "open source", but not "free software". Open source is freedom-agnostic: you can use it to hurt users just fine. The current iterations of remote attestation is especially egregious, because most of it is the government itself or an entity the government forces you to deal with (banks).
In general I believe remote attestation is actually fine, so long as it does not transcend ownership boundaries. A company can use it to ensure its own colo servers aren't tampered with, for example. But an external authority shouldn't be able to exert control over something I own. In particular there should be no expectation that my device is "trustworthy" in any way at all. Anything else ends privacy and freedom as we know it.
> this will effectively ban all open-source implementations
This is the only point where I differ: it will effectively ban most implementations, with no regard for whether they’re open source, closed source, or private. 1Password could be open-sourced tomorrow and continue being an approved implementation, no sweat, because they can be trusted not to disguise and release “export your passkeys as plaintext at rest” functionality — but in today’s market, there are certainly a thousand implementations (whether source or not) that died on the vine, whose sole purpose would have been to circumvent that one restriction, far more than there are implementations that are willing to genuinely try to uphold it.
Glad someone else is fighting for repurposeability — but there is no universal answer for how to balance privacy, freedom, and security. It’s something people have to decide for themselves, and just as my phone has an “highest security, lower convenience” mode for certain scenarios, so too I wish it had a “no security, total modifiability” mode for other scenarios. (Even if that denied me app store access, and I would demand that it wipe pre-existing passkeys from the HSM when I enabled freedom mode, or else it’s just an uncontrolled attack vector!)
It was perhaps not phrased that well. I meant that it would prevent passkeys from being used on user-controlled systems at all, since there wouldn't be a way for a passkey implementation to hide the attestation key from the user if the user can perform arbitrary modifications to the operating system. It will end up exactly like one of these DRM schemes, where you can't watch more than 720p videos on Linux.
Remote attestation in general is a backdoor to software freedom and ownership bestowed on you by free software, in the same way that tivoization is. Tivoization prevents you from running a modified version of the software on the same hardware, while attestation discriminates against you for running a modified version.
I do agree we should have repurposeability, but that's mostly independent of this attestation topic, IMO. I also think the tradeoff between security/privacy and freedom is greatly overblown. There is some, but giving the user an adb root shell or ssh server with key will not significantly decrease security of the user on Android. (It might reduce the security of the apps against the user, but it shouldn't be there in the first place). I'd be fine with not having app store access if it isn't mandatory for daily life, but that's not the case in our world.
> they want the keys stored in an encrypted way, is that too much to ask for
Well, they are encrypted but the issue is talking about exports. The maintainer of KeepassXC already mentions the issue with that: portability. A backup of such sensitive data (a password manager) is going to be stored somewhere secure (to the user) already. Why would you encrypt the contents and add another layer of complexity that other tools may not be able to handle? I want to be able to rely on those backups in the future and copy paste them around manually if needed. It's user choice, put simply.
A specification committee should never be deciding what a user does with their data, period. The security maximalist is always going to advocate for the most secure thing but most of the time that's not practical or friendly to humans.
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?
Genuine answers:
- because I like backing up my data, especially credentials
- because I like looking at how things work in practice - you are on a website called hacker news after all
it's mine.
Exactly. It's beyond me that people have to fight to use what they own as they please, or even are asked to justify themselves...
> 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.
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.
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.
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.
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 should do as I say.
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.
That's interesting. How the actual passkeys will be stored with this approach?
No thanks, it stinks.