![]() ![]() Therefore, anyone with the hash and access to the vault can still access all passwords without your knowledge. That gives you a reasonably strong password for the vault. The hash is then used as the password to open/lock the vault. For that to work, you'd insert yubikey, enter a password, and the password is passed through the yubikey and hashed. Reading it, it sounds like they use HMAC challenge response for the password to the vault. It's also a good way to hedge against types of compromise where only your password manager is affected, from vulnerable browser extensions (see LastPass, among others) to the possibility of weak crypto (which would be especially devastating for password managers that use centralized online storage) or even backdoors. A compromised password manager database including TOTP secrets effectively gives them access to everything at once, whereas any other kind of compromise would require a lot more effort to get everything, and would probably increase the odds of detection. The difference lies in the amount of effort an attacker would have to go through. U2F doesn't help with this aspect either, it just adds phishing resistance. Just to make sure no one gets the wrong impression: You still have a single point of compromise, as having sufficient access to your machine would allow an attacker to do anything from intercepting your TOTP code to stealing your session or just sending requests from your device. You'll also need to wait for them to figure out how they want to use the libraries required with their packaging system. Someone with more experience/patience/persistence, please, you can take the patch and rebase it and clean it up to what they want. I honestly thought someone else would take it up after I gave up to get it in by 2.2 (it's not even a very big patch), but. The other PR on updating their Docker to get newer libraries (libargon2 and libgcrypt) is ( ). The PR is ( ), you can read it, I know I sound rather impatient here. I agree that it should be separated, but at that point I already gave up on getting them to accept my patch. They also disagreed with the way I implemented KDBX 4 (by adding conditionals to the KDBX reader/writer instead of just creating a whole new class - I did this because KeePass did it this way). Then we (they) spent a week or two debating on how to support libargon2 and the newer libgcrypt required for ChaCha20, coming to no resolution, and I just lost any motivation to push for them to merge my patch. One of the KeePassXC guys asked me to rebase it over so I did. I wrote the patch against the original KeePassX which seems to be no longer maintained (?). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |