KeePassXC 2.2.0 released with YubiKey and TOTP support | Hacker News Reader

KeePassXC 2.2.0 released with YubiKey and TOTP support

keepassxc.org

314 pointsweslly130 comments

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?

You can try options UI on https://mauron85.github.io/keepassxc-browser/preview/

awesome will definitely signup to be a beta test when you get it where you want that.

actively using lastpass now and would like to move to an open source solution I feel like I can trust

You can go fully OSS already. Try https://github.com/pfn/passifox. It is using KeePassXC http protocol. I'am working on it's replacement.

Any chance of creating an Opera version as well? I just force installed the chrome version on Opera, but it doesn't seem to work.

I'll take look. If Opera supports webextensions, then it should be viable.

The official and latest version is always available here: https://github.com/varjolintu/keepassxc-browser

Firefox Nightly (version 56) is also supported. The extension will work officially when Mozilla releases build 57.

A few things to be wary of:

* 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

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 :)

chromeIPass' possible vulnerabilities being?

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 :)

Also, any autofilling is disabled by default.

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.

Can I talk to you about an idea I have regarding automating authentication extensions? There's no email in your profile, I'm afraid.

Have you considered dual browser extensions as in this paper:

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.

Interesting idea. Gotta read the paper. Thank you.

Still no KDBX 4 support though?

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

That would be me.

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.

Hope somebody cleans it up and adds the PR to Keepassxc. I would but I am not a C++ guy.(only Python guy sadly)

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.

> we only have limited resources

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...

I thought we settled on the PPA approach.

Congrats for your work there. It's sad that they asked you to refactor before raising the separated class issue.

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.

Previous discussion of this: https://news.ycombinator.com/item?id=13468486

There doesn't seem to be active development on KeePass/KeePassX, hence the KeePassXC fork.

The C in the fork title apparently stands for 'community'. It has a lot of support behind it.

No active development? I'm using KeePass on Windows (and have been for years) and I've just had a new update pushed (2.36)... Am I missing something?

KeePass is actively maintained, keepassx is the non-mono port for unix and is not being developed actively. Keepasssxc is fork of keepassx.

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.

There are two different variants of KeePass: the Windows version, and a KeePassX precursor.

I believe the idea is to merge XC back to X down the road. Not sure if that goal changed.

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.

It doesn't necessarily have to be multiple UIs (although that's probably better in the long term) but there are x-platform options like:

1) Eto.Forms (https://github.com/picoe/Eto) 2) Avalonia (https://github.com/AvaloniaUI/Avalonia)

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.

[Edit: missing word]

Wow thank you for the kind words! Appreciate the support.

You're welcome, it's a very decent effort. And now I'm sort of shamed into actually contributing. Reporting back as soon as time allows.

Yep we are now switching to advising its use for the human rights defenders and journalists that we work with.

I find it almost better than the original KeePass 2.x program.

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.

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.

https://image.ibb.co/k1amA5/kxpc.png

I use Command-L to lock, for what it's worth.

I'm still waiting for it to arrive in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855173

You guys rock! Thank you for your hard work.

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...

corrected thank you! I also added links to the 32-bit variants.

Notable features:

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!

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?

>We all know that you shouldn't store your password along with TOTP secrets

https://xkcd.com/1053/

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.

Though I do use U2F anywhere I can.

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!

Have you tried the snap install ?

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.

keepassxc from snap is starting much longer. at least 5sec diff

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?

It is because of a sandbox feature. You can't easily disable it right now.

I would try the symlink approach for now. Possibly drop a file next to the DB on your share in case you have to do it again and don't remember.

Thanks for confirming. I'll string something together.

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.

It makes me kind of sad that we're moving to a world where a 500 KB program gets installed in a 80 MB container :(

EDIT: Wait, now it's downloading a second 80 MB container :(

Yeah, what's up with that? Is it going to download one of these every time? That's awful!

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.

Why specifically during day/evening/quarter? Why not all three at same time? Just asking. Thanks..

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.

Or maybe I am just procrastinating.

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.

Decent mobile support is the only thing holding me back from switching. The current 3rd party options are underwhelming.

I just wait for Android O Autofill Framework to arrive. Then mobile password managers will finally be useful.

Really?... The syncing and conflict resolution (or lack thereof) is the true problem for me.

Keepass2Android works great for me syncing over OwnCloud (they have several cloud sync options)

Could be a problem with a shared database though as the entire thing is one blob, changes can't be merged.

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.

It's not perfect. It is slow because it uses Android's accessibility service to detect fields.

Ref: https://lastpass.com/support.php?cmd=showfaq&id=8166

I see it supports Linux, Windows, and macOS, but are there any Android and iOS apps to open and modifty KeePassXC databases?

If you feel like keeping your kdbx file in Dropbox you may use ikeepass[1] on iOS to load and modify it. For Android there is keepassdroid [2]

[1] https://itunes.apple.com/us/app/ikeepass/id299697688?mt=8 [2] http://www.keepassdroid.com/

I have had a good experience with Keepass2Android. It has support for databases on Google Drive.

Thanks, I actually use Keepassdroid. However, can it open databases from KeePassXC? (Well, I guess I can check a bit later myself.)

I use MiniKeePass on iOS and have been very happy with it.

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?

I'll answer part of my own question- this does look like it's compatible with the Keepass protocol 2. So that shouldn't be the reason to stop.

Of course there could be other reasons.

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.

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.

3. Lacking Unicode support in 2017 is simply unacceptable: https://i.imgur.com/X0T46bY.png

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.

Yeah I just downloaded. This seems like a good native drop-in replacement. Even the menus et all seem to be in the same place.

And Unicode works, yeah!

I have a really old computer and keepass2 opens stuff instantly so I'm guessing I'm probably not using good enough security.

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.

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.

Would you be so kind to file a feature request for that on GitHub? Thanks!

Done (#680).

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.

Docs are.. sparse. The website says go to the GitHub wiki, and that only really talks about how to build and develop the app, not how to use it.

Can anyone tell me how to enable Yubikey?

Just plug it in. ;-)

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.

pass no longer uses pwgen as of version 1.7, by the way (changed in 639c46a342466209e9b0600c2b3574bb44a0ff31).

I think Yubikey can be used to unlock the database

Features I like:

1) Download website favicon (no clue how though, tried entering website but didn't see an option to download favicon)

2) Command line interface, no clue again how to use.

For 1) Download favicon option is there inside "icon" menu of a keepass entry. https://keepassxc.org/images/screenshots/macos/screen_003.pn...

I wish there was a way to download and associate favicon of all entries in one-click.

Indeed, wish there was more documentation on how to use the CLI

Same here. I was hoping to run this completely headlessly but any attempt to run even `keepassxc --help` or `keepassxc --version` results in:

  QXcbConnection: Could not connect to display 
  Aborted

Can you open an issue on Github? Thanks

EDIT: I originally created an issue for the wrong repository, and it looks like someone has already made an issue for me: https://github.com/keepassxreboot/keepassxc/issues/668

Thanks for your attention

Okay, issue 254 has documentation on the CLI. Looks like you can't query password if that's what you're after

It also now has CSV importing so you can now import your passwords from LastPass (though you'll have to manually recreate the folder structure).

Doesn't work for my DB ... "Unable to open the database. Duplicate custom attribute found". Gonna stick with MacPass I guess.

Can you open an issue on Github?

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.

This is really cool. Here are more feature requests (and for all I know they're already there):

* Optionally display a secret as a QR code

* Generate and validate BIP39-compatible seeds (like Diceware but with a checksum. Many Bitcoin wallets these days accept them)

* Get this into Tails

Would you be so kind to file a feature request on GitHub? Here it gets lost. Thanks!

Done!

https://github.com/keepassxreboot/keepassxc/issues/675

https://github.com/keepassxreboot/keepassxc/issues/676

https://github.com/keepassxreboot/keepassxc/issues/677

Great release!

Is kdbx format supported by any iPhone app? I'm stuck with KeepassX for that reason.

Try MiniKeePass.

It works well but has some actions flow to sync your kdbx backups with updated data from the phone and vise versa.

https://itunes.apple.com/us/app/minikeepass-secure-password-...

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.

Anyone knows how should I change the font? I know this seems a minor thing but I'd like this thing to be readable :-).

The font-size is too small. And I'd prefer a font of my own choice.

How well does it work for teams? Is there issues for syncing the database if two or more people are using it at the same time?

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.

Nice! Excited for future development of this. I'll have to get a Neo soon to try out these new features.

I'd love to be able to decide which characters to use when generating a password.

You can already select a char-set. Do you mean selecting only a few chars and use them to generate the password?

Yes. Single special characters.

No KDBX 4 support unfortunately.

Storing password and TOTP seed in a single storage goes against the concept of 2FA.

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.

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?

Is there a KeePass fork with support for the new MacBook touch bar?

How is KeePassXC comparing in verification/testing vs the original KeePass2?

I was not able to find information on that process on eithers project homepage

Reply on news.ycombinator.com