Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So if a client ever goes rogue someday (either intentionally or has been compromised) and starts shipping off private material to a malicious third party, you think relying parties shouldn’t have the option not to trust that client anymore?


Sure that's bad, but the trouble is you're not thinking about what the alternative is. If users don't have control over their own data, then someone else does.

As stated by the spec authors on KeePassXC's bug tracker, open source software may be modified by the user, so cannot be trusted. The passkey proposal is for all of your keys to be managed by proprietary software validated by your phone or your computer's TPM module. That means one of three big, US-based tech companies will control all of the world's login data. Those 3 companies are all currently involved in the largest fascist-taint-tongue-polishing in US history, and we want to hand them control over the world's logins. That's a much, much bigger risk than some users doing something stupid.

The spec needs to be written with the assumption that the user's private keystore may be hostile to the user's own interests, because in the real world, it is. It needs to be written to mitigate damage to the user from a hostile keystore. Instead, the spec places total trust in the keystore. This is a fatal error.


By all means, make a proposal to the FIDO Alliance that solves all these problems without introducing new ones. You're going to have to anticipate all the objections and be prepared to answer them, though.


I'm not the one trying to push a new standard, but sure, I'll do it for them. Explicitly allow users to export and back up their private keys in a documented file format, make client banning hard/discouraged, and no longer maintain a naughty client list. That's it.


Doesn't doing so necessarily lock out all the users using that client?


It would, yes. Thus it’s an action I would only recommend if doing so would help prevent serious injury to their customers. If it comes down to a choice between locking a customer out and having, say, their money stolen, then the scale tips towards safety.


Perhaps, but then (as always) we're back to the security of the recovery workflow.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: