Keepassxc: U2F

[sanawu]

Benefits of software U2F implementation

1. Full control over device key, the seed and private key
   
   
   
   1. Ability to perform CRUD operations on the critical value, the private key, nobody else knows this secret, it is YOUR secret, not the vendors, or anybody elses (this is reason alone to not trust hardware keys)
   
   
2. Zero cost of entry and adoption
   
   
   
   1. No hardware cost of entry (there should be no cost barrier of entry for security, not everybody's situation is in the same)
   
   
   2. No hardware cost of redundancy with multiple instances for backup (that doubles the initial cost at least as you are recommended to register a backup hardware key)
   
   
   3. Higher adoption resulting in more secure online presence
   
   
3. Open source methodology
   
   
   
   1. Reproducable builds, you know what you have built
   
   
   2. Reviewable and open and a faster feedback / fix loop with transparancy
   
   
   3. Everything about hardware keys today goes against the principles of being secure, it relies on trusting a vendor without verification of the vendor, it relies on obscurity and being closed without verification, it relies on a secret that is not created and controlled by the user and sitting somewhere out there out of your control, by default it is compromised
   
   

Reason why current hardware keys are bad

• Closed source and unable to verify implementation, we know from history this is bad, every time
• Cost cutting implementation weakens the security via embedded non viewable, non changable device key/seed to reduce storage on public/private key generation per authorisation [1]
• Wrapped key derrived from embedded device key (seed) is transmitted instead of a random index generated weakening the implementation [2]
• RSA SecurID, 2011 seed theft, similar weak/compromised principle, vendor created the device key/seed at point of manufacture and embeded it unchangable, stored it locally, stolen from the central vendor database resulting in compromise and all sold hardware keys rendered compromised [3]
• Made in territories that are known for inserting mal/spyware into hardware devices and apps to reduce costs [4]
• Not all vendors implement U2F the same way, there is leniency in the specification with regard to implementation and without open source it is impossible to verify implementation

[1] https://security.stackexchange.com/questions/149989/generation-of-keys-for-u2f

[2] https://crypto.stackexchange.com/questions/25332/yubicos-take-on-u2f-key-wrapping

[3] https://arstechnica.com/information-technology/2011/06/rsa-finally-comes-clean-securid-is-compromised/

[4] https://www.cnbc.com/2018/08/30/google-titan-made-by-chinese-company-feitian.html

Those who ignore history are doomed to repeat it, I expect a future heist of device keys to tarnish the hardware keys yet again like 2011

If it is not your key (device key/seed), then you are not secure, you may own the hardware, but you do not own the devicekey/seed

[phoerious]

Can you stop spamming us with this?

[normanr]

@sanawu: It sounds like software U2F isn't a feature that the devs want to implement and maintain in KeePassXC. It doesn't matter if it's hardware or software, there will always be bugs. One critical feature that software U2F will never be able to implement is: "you notice if someone has stolen your token".

If you're looking for open source (hardware) try https://solokeys.com/ or https://www.nitrokey.com/. If you're looking for (open source) software solutions try https://github.com/danstiner/rust-u2f (for Linux) or https://github.com/github/SoftU2F (for macOS).