>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.
Hi there, lead developer of KeePassXC here (and writer of a lot of code). The TOTP and SSH Agent are generally not a security issue. TOTP has no external interfaces and SSH Agent only writes to the known interface standards of those programs. There is actually not much to those code areas.
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.
> KeePassXC is written well and exercises defensive coding sufficiently.
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.)
I thought audits were usually of the form "I looked for vulnerabilities in this code, and found the following", which isn't really a value assesment. I mean, yes, the point of doing that is to have the basis on which to form an opinion about "is this software safe/secure?" which is absolutely a value judgment and at least partially subjective, but I didn't think the audit itself tended to concern itself with that?
IMHO an audit should always report about how readable a codebase is, because it's a dependency for the quality of the audit. E.g when the 1st kubernetes audit pointed out that the (side-)effects of certains operations are too complex to understand, this gives some insight about the height of the possibility for uncaught bugs and the possibility to introduce new bugs.
Most important any audit should state methodology and assumptions and report findings based on this.
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.
If the browser extension allowed leakage, I'd expect it to come from prepared pages and a JS exploit that can fake other origins, or from some stupid DOM information leak of the injected popups.
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?
Audits are neither proofs nor value judgements (these are not the only two things in the world).
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.
Personally, I think I want auditors to try to assess this.
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.
> If no actual security issues are found in an audit, that's good, but I want to know about the potential for them, too.
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.”
That’s important information, and should be included in a public announcement of an audit!
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.
It is worth noting that most users use KeyPassXC with the mobile applications Keepass2Android or Keypassium on Apple. A complete picture of the security of the system must therefore necessarily include an audit of these tools as well.
Hi all. Zaur here, the author of the audit report.
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.
When you evaluate Keepassium could you look into if the application honors not contacting anything on the internet? For me this is a major point of feeling secure when using the application and iOS has no way to block apps from accessing the internet.
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.
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
Even if you don't encrypt your Linux' filesystem partitions, you definately should encrypt the swap / the partition the swapfile is on. A new encryption key for the swap can be created at every boot, removing the need of an encryption password. This behaviour does make hibernation impossible, so swap encryption isn't the default on Linux distros that have opt-in encryption.
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.
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).
> I have been meaning to leave lastpass but always seems like too much hassle
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
Lastpass like pretty much any modern password manager has zero knowledge of your encrypted vault so regardless of how crappy the service they physically cannot leak your data. This is the reason why encryption exists, to move secure information across not just insecure, but even adversarial channels.
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 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.
Syncthing (the most recent versions, at least) also allows for password-encrypted sharing. So even if you are syncing across a relay, no data is in clear.
For something like KeePassXC, sync your kdbx file across all of them with your choice of cloud drive. Secure it with a key file you manually add to each of your devices but do not include on your cloud drive and a good password.
Keepass on pc and on android. The android saves as .kdbx files, which once saved as such, the pc reads and writes (default is .kdb files). I also use a keyfile common to both devices. Manual sync as i update irregularly.
Nothing touches a cloud, everything stays with me. My .kdbx files are steganographically encoded, and the file extension is changed.
Seems cumbersome - isn't.
pass (passwordstore.org) backed by a remote git repo works well across Linux, Windows, macOS, iOS, and Android, as all of them have decent clients available and there is working browser integration for all popular browsers using browserpass (https://github.com/browserpass/browserpass-extension).
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.
In my opinion, this is one of the most secure options.
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.
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".
That’s part of the appeal. It allows for sandboxing each password to its own vault essentially (you pay a privacy cost, which I don’t mind anyways, and my disk is encrypted).
I self host vaultwarden (formerly bitwarden_rs) and use the bitwarden clients. This is more of a lastpass-esque experience than KeePass in a sync program, which was my previous solution from about 10 years ago to about 3 years ago when I switched to bitwarden.
How do they compare? I've been eyeing Bitwarden for a while only because there's an iPhone in my household and it doesn't support Syncthing, so we end up manually syncing the DB on that device occasionally. It would be great to avoid that manual sync.
For me the big advantage was just never having to think about sync conflicts ever again, which happened to me often enough to be annoying. There's also things like the browser integration is more streamlined, using the bitwarden CLI is convenient in some of my automation, and while android supports syncthing, android has always been a bit less reliable in desktop platforms in allowing syncthing to run in the background or in allowing other apps to know that syncthing has updated a file.
I actually moved from Dropbox to Syncthing as I found Syncthing more reliable, as Dropbox would sometimes generate spurious conflicts even between my desktop devices.
I encrypt with gpg and upload the .xkdb file (itself already encrypted) to a server I have access to with scp.
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.
I keep my KeePass file on my OneDrive / iCloud account. This way it is always up to date as it syncs automatically after each change and my devices always open the most recent version.
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.
Do you mean the App to open the password database, or the App for syncing the file?
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.
Not doomed in the least. I self-host vaultwarden (and many other services) on my home network and access them from mobile devices (web and/or bitwarden app) using wireguard.
There is an app on Android at least called "pass" that allows you to do this.
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!
>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.