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?
As far as I know, localhost can't be intercepted. Except for unintentional mistakes such as binding to 0.0.0.0 instead of 127.0.0.1.
And inevitably there are going to be some tinkerers who'll run it over the network because it suits them.
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.
Well, yes, that's the goal. But it's surprisingly easy to mess up. I think the people here are cautioning you not to get overconfident, and to make sure you research the details of the flaws in other systems.
It is easy to mess up, yes. I'm not overconfident, but almost the opposite. Without being totally paranoid, I'm usually pretty certain something important is forgotten. All help is welcome :)
KeePassXC restricts chromeIPass to localhost, so data should be safe. Still, chromeIPass exchanges encryption keys in base64. Basically that's plain text. These are the only keys used, so technically it's possible to steal those keys (if not localhost). But if someone has permission to read your loopback or local packet traffic, your info is gone..
Other than that, chromeIPass uses quite old libraries and depricated API functions. Those haven't been updated in ages. keepassxc-browser should fix all issues mentioned above :)
>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.
I understand, but I'm still disappointed. You all only needed to come to a decision on how you wanted to proceed with supporting the newer libraries required and I would have taken it from there. I'm not sure if you guys have even now come to a decision on that.
And it took a month before someone mentioned they would prefer if the KDBX 4 functionality was separated (and I do agree that it should be).
You could probably merge a similarly-sized patch into the kernel in less time...
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.
The larger problem on cross-platform KeePass was never Mono directly (aside from the FUD), but rather the WinForms UI. One could blame Mono for not having a visually pleasing implementation of WinForms, although .NET core has nothing at all.
Refactoring out a core and building multiple UIs would be an interesting and large project.
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?
I store them in the same password safe for quite a simple reason; more convenient and less complexity.
I personally see TOTP only as a security against phishing and password stealing attacks. I don't see how a separate database for TOTP secrets improves on that in any way.
The thing is; a Keepass Password is (usually, looking at your password requirements Paypal) fairly secure in of itself, long, random and contains all the good characters.
TOTP is mainly useful when you have weak passwords and enter them into the wrong place, something that Keepass (especially with the Browser Extension) fully prevents. It's just for show and some extra padding.
An official ppa repository for Ubuntu would be great!
There is a link to an unofficial one in your page, but since this is a security app, installing it from some random repo just feels wrong... Thank you for the great work!
Sorry to hijack the thread a bit, but since you're discussing the snap install I thought I'd ask. This is the first snap app I've ever used. I find the file browser for opening the DB won't show anything outside of my $HOME. I assume this is some sort of sandbox feature of snap apps. But I'd like to store my DB on a network mount, so that gets in the way unless I set up symlinks. Is there any way to get this to behave a bit more like a normal desktop program?
The snap is great! Yes, the theming current is not perfect, and I've noticed the longer startup time. But yesterday my RSS reader showed this post (actually, the Github release page a little earlier) and one impatient `sudo snap refresh` later, this new version is installed, direct from the upstream, without any extra repo or PPA that could replace my kernel.
Yes I did that, but the gui looked horrible, as it was not using my themes, colors etc. I then found out that this was a known issue of snap at that time.
Has anyone thought of a good redundancy scheme for yubikey?
Physical object authentication is great except physical objects are less durable than brain memory (or at least, if my brain memory is gone then I probably would have no use for the password anyway).
Keep 1 key on your keychain, one in a fire vault in the house, and one in the safety-deposit box at the local branch bank office. Most U2F-enabled sites let you register multiple keys. Add new sites with keychain during the day, in the evening add the fire-vault key at home. Once a quarter add the third key from the safety-deposit box.
Because you need the key with you to register it with a site, and if they are being stored in separate locations, you need to do it when you have access.
I am playing with YubiKey storing certificates, then using the certificates like any other GPG setup, so I can have redundancy and revocation. But I have yet to make it dead simple enough to use for real-world application.
This release looks great. Unfortunately I had to switch to LastPass to get sharing, real sync support rather than blob syncing in, and also easy usage on mobile.
Interesting, how will it be better? The Lastpass for Android autofill in both native apps and web is already pretty perfect in my experience, it detects the fields and fills in the login. In the very rare case it doesn't, the notification list will have a one-click entry to force-fill the info.
For standard keepass I use keepass2android and nextcloud for syncing. That said I don't believe it supports any of the fun new stuff from KeepassXC. It does work with NFC and HOTP though. I'd love to use TOTP instead.
Thumbs up for Keepass2Android. Extra two thumbs up since it provides also a version without network capabilities for additional peace of mind, I found that a great touch.
As someone using Keepass2 (mono on Linux), can someone knowledgeable briefly tell me (and probably others) why should and why should not I switch to KeePassX?
I'm getting the feeling that this uses the older protocol?
I got a good answer to the above question from desdiv so I'm adding an edit:
Is there a reason to use this (and not use this) in place of KeePass2 on Windows?
1. Unlocking the database takes much longer than it should. Linux Keepass2 is much slower at unlocking than Windows Keepass2 on the same machine.
2. On Linux, after entering the password the windows disappears, giving no UI feedback during the lengthy unlocking process. When you type the password wrong, it takes even longer for some reason, and there's no tray icon when you type the password wrong, so you'd have to minimize all your windows to find the dialog box all the way in the back.
None of this is the fault of the Keepass developers, since all three problems are absent in the Windows build. As far as I can tell the problem lies with Mono.
It might take slightly longer, sure, but just slightly (instant vs maybe 0.5s at most). Maybe my database isn't big enough (~200 passwords) for this to be annoying, but it's certainly not that bad.
KeePassXC does support the KeePass2 format (i.e., KDBX3). It does not (yet) support the very latest format (KDBX4), but by default KeePass also still uses KDBX3, so both are compatible.
One thing I like about the KeePassX interface is the ability to search with a hotkey (CTRL+F). Also, this could be done without having the menu bar visible, hitting the hotkey just pulls up the input field.
I use MacPass, which is a good native Mac alternative for KeePass. It supports KeePassHTTP and judging by their github wiki they have recently implemented support for the KDBX4 format.
Can someone explain how the YubiKey and TOTP support is supposed to work? I can't think of a way those could work with a local password manager like KeePass.
Reading it, it sounds like they use HMAC challenge response for the password to the vault. For that to work, you'd insert yubikey, enter a password, and the password is passed through the yubikey and hashed. The hash is then used as the password to open/lock the vault. That gives you a reasonably strong password for the vault. It does not prevent phishing. Therefore, anyone with the hash and access to the vault can still access all passwords without your knowledge. The TOTP thing sounds like a google authenticator sort of feature.
I'm sticking with zx2c4 pass. It is an assembly of gnupg, git, and pwgen. Trusted open source components. Works with a Yubikey (opensc and gpg-agent) to prevent private key theft via software. QTPass is a nice cross platform gui client. PassFF extension provides excellent browser integration. Android Password Store and OpenKeychain allow pass and yubikey to work on my mobile. Strong 2 factor password storage everywhere I need it.
My biggest problem these days is dealing with sites that don't allow 30+ char passwords with full range of special characters. Almost exclusively, banks.
Well done! It's great to see some progress with open source in this particular area.
At the moment I'm still stuck with [insert_name_of_commercial_proprietary_solution] but would love to switch to a true open source solution with good user experience and reliable mobile support.
I will make a small donation as soon as I get through the flattr waitlist as a small token of appreciation.
I'm trying the snap package, but I don't think the cli is available this way. I can find the binary in /snap/keepassxc/current/bin, but it has library loading problems.
Works OK for small teams. If a user forgets to close the database then other team members are only able to open it as read-only. My biggest gripe is that you don't know who is holding the write lock. We work around this by using a setting in our keepass client to close the db after a certain amount of time.
Well instead general password without password manager assumes the fact someone remembers that password. (and perhaps reusing that password.) Using password manager (with different password for each service) plus TOTP would serve its purpose. You still have to enter the code, so it still require you to "have" that code somehow which makes it no different than provisioning multiple devices which many 2FA systems won't prevent, perhaps other than hardware TOTP devices.
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/