Really good timing for me to self promote. :-) I'm working on improved keepassxc browser extension. Communication between browser and KeePassXC is via NativeClient. You need varjolintu fork of KeePassXC, but eventually it will also support KeePassHTTP protocol too.
My goals currently are: internalization, nicer UI, clean and extensible code base. I already did options page with material-ui and react. Currently working on replacing jquery popup implentation for hyperapp, which appeared here on HN yesterday.
If interested I can send instruction how you can build extentions. I would like to see this as official part of KeePassXC and willing to donate for free. What you guys think?
* KeePassHTTP doesn't use authenticated encryption for its protocol and thus is insecure (decrypt password level insecure). Please make sure you don't have this issue.
* Browser integration means there is only some JS code between my unlocked password vault and random websites. Please study findings from Tavis Ormandy and others who found such vulnerabilities in LastPass et al
Your second point is a great point, and I believe that there should be a user prompt every time something tries to read from the password database over any API.
With that said, what's the threat model for the first point? Is localhost interception a serious risk?
keepassxc-browser uses libsodium's box method for encrypting the messages. Only public keys are transferred between the extension and KeePassXC. You still need a valid private keys and a nonce for decrypting and encrypting the replies. You can read a more detailed description from the github page.
I have been keeping eye on the vulnerabilities and going to be very careful when it is time for a final release. Currently if there's any vulnerabilities, these are almost identical to chromeIPass' possible vulnerabilities.
>The prototype Horcrux client, implemented as a Firefox add-on, is split into two components, with code that has access to the user's master's password and any key material isolated into a small auditable component, separate from the complexity of managing the user interface.
Please consider making it a priority - it looks like someone tried to pull request it but that failed? The older format uses a custom AES-based KDF - and while I don't personally see any major issues with it, I'm much more comfortable with the modern, heavily reviewed Argon2 design used in the KDBX4.
I wrote the patch against the original KeePassX which seems to be no longer maintained (?). One of the KeePassXC guys asked me to rebase it over so I did. 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.
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). I agree that it should be separated, but at that point I already gave up on getting them to accept my patch.
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.. I guess not.
Someone with more experience/patience/persistence, please, you can take the patch and rebase it and clean it up to what they want. You'll also need to wait for them to figure out how they want to use the libraries required with their packaging system.
KDBX4 is a priority indeed, but we only have limited resources. We hoped to get it into 2.2.0, but it just wasn't possible. We really appreciate your patch and will make sure it lands in 2.3.0. It's not forgotten.
So there's KeePass, KeePassX, and now KeePassXC? (And two different variants of KeePass that have nothing to do with each other.)
Not that there's anything wrong with that. I'm just curious if KeePassXC is yet another fork, or if it's from the same people who did KeePassX. KeePassX has an excellent security reputation, so it'd suck if an unrelated fork ruined that.
KeePass (the original C# version) appears to actively developed. KeePassX (the C++ rewrite) appears to have slowed down. KeePassXC (the fork of the C++ rewrite) is the one under discussion here.
KeePass is the original, and also not very cross-platform. KeePassX has gone through several iterations and now represents a fairly stable and low-feature release of KeePass with cross-platform support. KeePassXC is where all the new and exciting features are being integrated into KeePassX while fixing latent bugs and cross-platform issues. Hope that makes sense.
Is there any thought to merging efforts with the original KeePass project? I know it's C# based but with .NET Core being an option now, maybe it doesn't require Mono and could be made cross-platform. Or maybe keep the C++ code and fold it back into the original project?
I just hate to have multiple projects spend resources on what is essentially the same thing. I think there are gains to be had by combining resources together.
Keepass is actively developed but uses .Net so Linux requires mono. So KeepassX was created to use C++ so Mono is not required but the project is inactive.
So KeepassXC was created as a fork of KeepassX for the linux users who don't want an ugly MOno version of Keepass.
This is by far the best of the KeePassX* lot, incorporating loads of enhancements which, disappointingly after years of development, never made it into KeePassX 2.x proper, and some 1.x features which simply disappeared in the upgrade.
I really like KeePassXC, it's the only password manager I use (excluding mobile) but my one major bugbear still exists in this release.
The 'lock database' and 'copy password to clipboard' icons are nearly identical (both essentially a padlock) and still adjacent but one in the UI.
I accidentally lock the database far more often than I would like. I know I'm a bit clumsy and a slow to catch on but this one simple change would really make application a lot more useable for us divs.
For anyone wondering - the TOTP 2FA is not on the password wallet itself, but that the wallet is able to store the TOTP key, authenticating TOTP involves knowing the key, by which point there's really no value in using it to authenticate the wallet, it'd be a UI-only protection.
However I think storing TOTP keys in your wallet is a bad idea for security - now if someone hacks your machine they get both your password and your TOTP key at the same time. The main advantage of TOTP is that it puts your second form of auth on a separate device, preventing a single point of compromise.
not much malware will exploit this as not many people will use it, but a targeted attack might greatly benefit from something like this.
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. U2F doesn't help with this aspect either, it just adds phishing resistance.
The difference lies in the amount of effort an attacker would have to go through. 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.
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.
Just to make sure no one gets the wrong impression: You should store your TOTP keys in a different KDBX file, locked with a different master password, and maybe even used on a different device/PC.
We all know that you shouldn't store your password along with TOTP secrets, or should I make a blog post explaining this?
Readit News
My goals currently are: internalization, nicer UI, clean and extensible code base. I already did options page with material-ui and react. Currently working on replacing jquery popup implentation for hyperapp, which appeared here on HN yesterday.
If interested I can send instruction how you can build extentions. I would like to see this as official part of KeePassXC and willing to donate for free. What you guys think?
You can try options UI on https://mauron85.github.io/keepassxc-browser/preview/
* KeePassHTTP doesn't use authenticated encryption for its protocol and thus is insecure (decrypt password level insecure). Please make sure you don't have this issue.
* Browser integration means there is only some JS code between my unlocked password vault and random websites. Please study findings from Tavis Ormandy and others who found such vulnerabilities in LastPass et al
With that said, what's the threat model for the first point? Is localhost interception a serious risk?
I have been keeping eye on the vulnerabilities and going to be very careful when it is time for a final release. Currently if there's any vulnerabilities, these are almost identical to chromeIPass' possible vulnerabilities.
Firefox Nightly (version 56) is also supported. The extension will work officially when Mozilla releases build 57.
https://arxiv.org/abs/1706.05085
>The prototype Horcrux client, implemented as a Firefox add-on, is split into two components, with code that has access to the user's master's password and any key material isolated into a small auditable component, separate from the complexity of managing the user interface.
actively using lastpass now and would like to move to an open source solution I feel like I can trust
Please consider making it a priority - it looks like someone tried to pull request it but that failed? The older format uses a custom AES-based KDF - and while I don't personally see any major issues with it, I'm much more comfortable with the modern, heavily reviewed Argon2 design used in the KDBX4.
https://github.com/keepassxreboot/keepassxc/issues/148
I wrote the patch against the original KeePassX which seems to be no longer maintained (?). One of the KeePassXC guys asked me to rebase it over so I did. 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.
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). I agree that it should be separated, but at that point I already gave up on getting them to accept my patch.
The PR is [here](https://github.com/keepassxreboot/keepassxc/pull/399), you can read it, I know I sound rather impatient here. The other PR on updating their Docker to get newer libraries (libargon2 and libgcrypt) is [here](https://github.com/keepassxreboot/keepassxc/pull/419).
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.. I guess not.
Someone with more experience/patience/persistence, please, you can take the patch and rebase it and clean it up to what they want. You'll also need to wait for them to figure out how they want to use the libraries required with their packaging system.
Not that there's anything wrong with that. I'm just curious if KeePassXC is yet another fork, or if it's from the same people who did KeePassX. KeePassX has an excellent security reputation, so it'd suck if an unrelated fork ruined that.
The C in the fork title apparently stands for 'community'. It has a lot of support behind it.
I just hate to have multiple projects spend resources on what is essentially the same thing. I think there are gains to be had by combining resources together.
So KeepassXC was created as a fork of KeepassX for the linux users who don't want an ugly MOno version of Keepass.
[Edit: missing word]
I say almost because I'm used to the original interface, but I'm sure after getting used to it, it will supersede it on my systems.
The 'lock database' and 'copy password to clipboard' icons are nearly identical (both essentially a padlock) and still adjacent but one in the UI.
I accidentally lock the database far more often than I would like. I know I'm a bit clumsy and a slow to catch on but this one simple change would really make application a lot more useable for us divs.
https://image.ibb.co/k1amA5/kxpc.png
BTW the Windows portable version link on your download page is 404ing:
Incorrect URL: https://github.com/keepassxreboot/keepassxc/releases/downloa...
Correct URL: https://github.com/keepassxreboot/keepassxc/releases/downloa...
1. Unlock using Yubikey
2. TOTP 2FA
3. Diceware password generator
4. ASLR for in-memory security (didn't expect this!)
5. Portable and Single instance mode (I'll have to check this one in detail)
Thanks for your work team!
However I think storing TOTP keys in your wallet is a bad idea for security - now if someone hacks your machine they get both your password and your TOTP key at the same time. The main advantage of TOTP is that it puts your second form of auth on a separate device, preventing a single point of compromise.
not much malware will exploit this as not many people will use it, but a targeted attack might greatly benefit from something like this.
The difference lies in the amount of effort an attacker would have to go through. 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.
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.
We all know that you shouldn't store your password along with TOTP secrets, or should I make a blog post explaining this?