| ▲ | FreakLegion 2 hours 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 2 hours ago | parent [-] | |
> 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. | ||