KeePassXC Audit Report
keepassxc.org
keepassxc.org
>As KeePassXC is a relatively complex program and the review effort was limited, I did not review all of the code base. Some helper features stay not reviewed, for example: TOTP, SSH agent, browser plug-in communication, auto-type, KeeShare password sharing mechanism, freedesktop integration, HIBP support, database statistics feature. Maybe these features could be a subject to a next review version.
Those integrations seem like scary weak-points, especially to the browser.. and I'm a little confused because later on he says he did review the browser extension code:
>KeePassXC supports integration with browser extensions. The communication between the password manager application and the browser extensions is implemented using secure and modern libsodium-style encryption. I personally trust this cryptography choice and salut the use of encryption to communicate with browser extensions.
Auto-Type is similarly rather simple at the interface level (except for X11 because its X11). We call native OS functions to emulate typing.
Similarly the internal reporting features are rather benign. HIBP checks requires explicit approval by the user before anything happens.
The browser code and FDO Secrets code definitely needs auditing. The browser extension is separate from the browser code within KeePassXC proper.
KeeShare is going to be entirely rewritten for our 2.8.0 release.
This might be a transcription or language problem, but: auditors really shouldn’t normative claims like “software X is written well,” much less actually endorse the software they’re paid to review (as the audit’s summary appears to at the end of the post). It’s a massive conflict of interest, and undermines the actual purpose of an audit: to accurately report any weaknesses found (if any!), rather than offer an opinion on the product’s value or future exploitability (including against unknown adversaries).
(This is not a dig at KeePassXC or this auditor in particular; lots of auditing shops are guilty of this.)
> It’s a massive conflict of interest
They weren't paid.
There's no conflict of interest, at least not a commercial one.
Even still: pro bono audits carry reputational value, meaning that there’s no way to fully discharge the conflict of interest here. The only correct way to do it is to refuse to endorse the software you audit; an audit that enthusiastically recommends the software it covers sets off red flags.
Edit: I misread the post, which does explicitly state that the audit was conducted for free.
The second point still stands.
* ask for donations to the author, and
* provides contact details of the author, in case someone wants to hire them to review their software.
We can debate whether these constitute conflict of interest.
Audits are - by necessity(1) - value judgements (otherwise we'd call them "proofs"). This audit concerned the source code.
I very much want a source code audit to make value judgements about the audited source code. That is its entire reason for existing, after all.
(1) audits involve examination and possibly testing. Neither of these can offer guarantees beyond "what we observed, is there / happened."
My big problem with KeepassXC is that the threat model is not well documented. It does a lot of fuzz around memory randomisation but it might be much easier to extract the secret key of the browser extension when unlocked. So I guess it mostly provides security for data at rest, but afaik this is not documented. A general security audit is IMHO difficult if nobody states any guarantees.
From each other, WebExtensions are sandboxed pretty well as far as I know.
I guess you're safe if you stick to always manually allow the password request and of course, practise the same amount of scrutiny regarding phishing as when entering passwords manually.
Or are you talking about the IPC between the browser and the KPXC app?
They’re closer to a procedural or logistical requirement, similar to a cross-check on an airplane. The FAA doesn’t mandate cross-checks because they prove that an airplane won’t fall out of the sky; they mandate them because they empirically reduce (but do not prevent) incidents.
For proofs, we have formal methods (which an audit can employ!). For value judgements, we have consumer groups and word of mouth.
There are certain risky / iffy coding practices (manual string manipulation in C, for example) that might or might not lead to actual security issues, depending on whether you make an error. If no actual security issues are found in an audit, that's good, but I want to know about the potential for them, too.
Yes, this is difficult to evaluate in an entirely objective manner, but I'd rather they just do their best because to me that's still better than no information.
That’s perfectly reasonable, and independent from what I’ve said: audits regularly document potential weaknesses, especially when vulnerabilities aren’t found. What they don’t generally do is make statements to the effect of “this software is high quality” or “we approve of this software.”
If version 4 is mores safe, KeePassXC should insert a nudge for their users to upgrade.
Thanks a lot for the feedback here. I've decided to clarify some points and also introduce changes to the most recent audit PDF. https://molotnikov.de/keepassxc-review
- The links in the most recent review version are now highlighted with blue.
- I did not yet have a too deep of a look in Keepassium, KeepassDX, or browser extensions, although, I know these exist. On my radar, need to find time and dive deep!
- The not reviewed features by me are just not reviewed yet. I wouldn't call them scary. The use of them is optional btw. Again, need to find time and look deeper. It is also a tip for other researchers where to look next.
- My review contains certain subjective statements like on quality of code, and on recommending the use of KeePassXC. Well, my goal was to inspect an offline, without servers, subjectively likeable and recommendable from the UI/UX perspective tool, because the main problem with the password managers is that they are still not used enough in the wild. I have found a subjectively good desktop UI, checked the code quality (structure, availability of tests, clean use of C++ and Qt), could see sound modern crypto, and.. proceeded to solving a bigger problem - recommending the use of it. Making the judgment for the potential review readers, to whom the deep details are too much to interpret, and who need a simplified answer, what to incline toward, if to rather use it or not... I noted though for the next reviews to avoid too general judgements.
- Personal questions on who Zaur is, and why my opinion matters.. :) Well, the CV is pointed to, I know applied security and applied crypto, I have 6 years professional experience with C++. I code and review projects for security daily. No complex and working software is ideal and perfectly secure. Plenty of software online is low-bar in secuirty. I had capacity to check the basics and a little beyond them for KeePassXC, and put my subjective judgment here on the right side of the weights.
- Loved the discussion on mobile phone and multi-device sync. Syncthing and other suggestions. On an iPhone nothing really works very well, as files are compartmentalized per app... For those of us who only need a few passwords on mobile, it is recommendable to create a separate small database with only those passwords, and use it readonly on the mobile.
Otherwise thank you a lot for checking KeePassXC!
You can also directly verify these claims using the App Privacy Report. It's a system feature that shows which domains an app contacted over the last 7 days (and how often). And it works for all apps.
Unfortunately, there is no way to _enforce_ the offline behavior of an iOS app, but being able to monitor it is already something.
> The memory deallocation could be improved to not to contain secrets after the database is locked though. See https://github.com/keepassxreboot/keepassxc/issues/7335 for progress on this issue
Then again, the PDF mysteriously doesn't indicate which words are hyperlinked and so maybe I just didn't wave my cursor over enough words to find those references
Also, because the outer blogpost didn't mention it (although it is in the actual PDF) the auditor is https://molotnikov.de/cv and it says they work for AWS as a Senior Security Architect. I didn't see anything especially C++ focused, but I guess any independent audit is better than none
Attacks against RAM are as old as time. The beauty of RAM is everything gets wiped when you power off, so secrets don't persist.
I think there is an API in windows to mark a small part of memory as unswappable, but it can't be very big.
https://wiki.archlinux.org/title/Dm-crypt/Swap_encryption
Does someone know how it's handled on Windows and macOS?
[1] https://github.com/arekbulski/Cameleonica/blob/master/docume...
[2] https://www.usenix.org/legacy/event/sec08/tech/full_papers/h...
Unfortunately, it isn't enabled by default but needs kernel parameters.
I understand firmware vendors are to blame, and in many machines the system will freeze when you attempt to actually use this feature. This is unfortunate.
On a few devices that never connect to the same wifi i use tailscale to connect Syncthing.
Using an additional shared secret on a folder allows you to sync a folder to an untrusted device, which then itself only sees encrypted files.
i've been running this scheme where i keep the "live" DB on my phone so any change i need to do, i do it on the phone and every often i sync or copy it to the laptop.
this has served me well for like the past 6-9 years so i guess it works. You definitely do not need an online service.
its not like passwords change like crazy. i've had entries that i only change because of stupid password reset policies (every 4 months for example), other than that, i only update the DB if i add a new entry.
On Linux and Windows, KeepassXC is my software of choice. On Android, I like (and have donated multiple times to) https://play.google.com/store/apps/details?id=keepass2androi...
With the cloud storage setup (which, in my case, happens to be Google Drive), I always have the most recent version of my password safe(s) where I need them to be.
With this, my major threat exposure comprises of * the cloud provider losing my data, letting an aggressor get hold of my (encrypted) password store(s) - and then the aggressor brute-forcing * I myself losing my password store data to an aggressor * I myself losing my password store credentials to an aggressor
I am explicitly not using any of the online password providers simply because they are by themselves a much too valuable target. I myself, hopefully, am not valuable (or visible) enough, and therefore am not subject to "at-scale" attack patterns.
I find this one nice, there's no need for a password manager to have Internet access when the database is synced with a separate client (in my case Nextcloud).
The kbdx file is encrypted, so given a strong password it should not matter how secure the app for syncing the file is. Most people seem to use it with syncthing.
The learning curve to understand all the moving pieces and the initial setup can be more hassle than many are willing to put up with, but after the initial legwork is done, adding new devices is not that much more complicated than what it is on paid services, and using it is as simple as any of the popular services, IMHO.
Pass is a short bash bash script (very little code). It passes the encryption to a dedicated utility GnuPG (out of which only the AES and cv25519 routines are used).
You should use smart card to store the GPG key. Every touch of the security key gives out only one password. So if you copy the HN password, other passwords such as your bank password is not at risk.
The missing part is integration with browsers, which increases the attack surface (although it’s minimal here, since only one password is at stake), but protects against phishing.
Pass probably doesn’t need an audit, since you can just read the script.
Only if you disregard that pass doesn't encrypt file names.
Gopass does encrypt file names too.
Also, I don't know if other people do this, but I don't actually use the pass scripts, and instead have my own scripts for managing things that just happens to be very similar to pass. I extend it in whatever ways I want to.
If I cared about this issue I would probably consider putting the passwords in a file system on a loopback mounted luks volume backed by a regular file, or maybe just store them in a different format altogether.
I do realize that the average user doesn't want to bother with all of this and wants something that "just works".
Not manually, and not only for this file: this is a system I have to sync the files I want in different machines, by running a little program I wrote (https://gitlab.com/jordibc/csync just in case). I would use syncthing otherwise, but this system has several advantages for me.
If I hadn't access to an online server, I'd use some cloud storage for the same thing.
For people without need for sharing, use cloud storage. Make sure to use an app that protects from writes from different clients though.
For people with need for sharing, you are doomed. (e. g. Family sharing)
I mean this in all seriousness: how have you stayed on Lastpass after the innumerable breaches? There's "my weekends are not best spent exporting and importing csvs" and then there's borderline criminal negligence of credentials one pays a company to keep safe
I mean, it's your life, I'm just genuinely curious how that calculus plays out
And none of the breaches have resulted in password loss if you used a strong pass phrase.
All the talk about PBKFD2 iterations has been about preventing loss when you used a weak password.
The same brute forcing for the most part also applies to keepass if you host your vault in ways that someone could access.
I don’t love Lastpass in anyway, but let’s not pretend that there was outright catastrophe.
It was bad that servers of a popular password manager with millions of users were compromised. The security controls were bad: a lastpass engineer had access to critical credentials in the same machine that he watches Plex open to internet (and possibly more).
It was bad because a lot of users don’t have strong master passwords, and their vaults are at risk. Also, insufficient pbkdf2 iterations did not protect well against brute forcing the vault. Sure users should use strong master passwords as much as possible. But a weak password would not have been a problem if the servers had not been compromised.
It was bad because a lot metadata has been leaked, that can be useful in further attacks.
A compromised server could also push a malicious update to the users and steals master passwords.
When you use cryptography you go through all the hassle exactly so you don't have to have a panic attack when a company behaves stupidly.
- It turns out a lot of the vault isn’t actually encrypted
- Some vaults used weak, breakable encryption
- The browser extension could be tricked into decrypting data for malicious parties
Encryption isn’t an on/off thing, it’s only as good as its implementation.
Also, this isn’t “zero knowledge” encryption, it’s end to end encryption.
Device B -> git pull from remote repo
¯\_(ツ)_/¯
The Android pass app is developed and distributed by the same person who maintains the Android wireguard app iirc, otherwise I probably wouldn't have trusted it!
You can then choose at some later date to migrate to self-hosting or not.