I've been a long-time user of KeePass. I inspected its 2.x .NET source code today and quickly noticed the following issues which I find quite concerning:<p>The kdbx database is encrypted with AES in CBC/PKCS7 mode <i>without</i> proper authentication. HMAC is nowhere to be found in the code, other than when used for sha1-totp. There are SHA2 hashes that seem to guard the integrity of ciphertext, while these might catch a typical file corruption they will not prevent malicious tampering. Even if the hashes are used prior to encryption, that's still MtE - not EtM.<p>KeePass likely does not have an online threat model, so attacks like Padding-Oracle might not be applicable, but a lack of AEAD is IMHO highly concerning because it indicates that the author(s) are winging it when it comes to doing crypto right.<p>Byte array comparisons are done with this function from MemUtil.cs:<p><pre><code> public static bool ArraysEqual(byte[] x, byte[] y)
{
// Return false if one of them is null (not comparable)!
if((x == null) || (y == null)) { Debug.Assert(false); return false; }
if(x.Length != y.Length) return false;
for(int i = 0; i < x.Length; ++i)
{
if(x[i] != y[i]) return false;
}
return true;
}
</code></pre>
There are many other questionable patterns, code smells, and "I-invented-it" approaches that indicate a non-expert .NET programming skill. They can't even implement a Singleton correctly (see CryptoRandom.cs).<p>Has anyone ever done a security audit of KeePass 2.x or does everyone just believe that it's "good enough"?<p>P.S. None of this detracts from the fact that KeePass is a very useful, free utility with a lot of effort put into it. I thank all contributors for making/improving it over the years.
I don't know that an HN thread is the best venue to discuss crypto design flaws (you might be better off writing a POC of some kind and then publishing that), but yes, it is a little disquieting to see a sensitive application using AES without an authenticator.<p>To the many readers of this thread who believe they don't care about the integrity of their password vault, just its confidentiality:<p>The problem is you can't necessarily have confidentiality without integrity.<p>Sound cryptosystems that provide integrity checking rule out chosen ciphertext attacks against the cipher: in order to submit a ciphertext to such a system, you have to get past a cryptographically secure integrity check.<p>Without that check, attackers can feed a victim systematically corrupted ciphertexts, which the victim will dutifully decrypt, and observe the behavior of the victim in handling them. This is the basis for a whole family of "error oracle" side channel attacks.<p>You generally don't want to trust the confidentiality of a cryptosystem that doesn't check ciphertext integrity and rule out manipulated ciphertexts.<p>As the poster points out: this might matter a lot less for a system that runs purely offline. Or it might not. I lean towards "not a super plausible attack vector". But who knows? Why be OK with bad crypto?
"On The Security of Password Manager Database Formats" (<a href="https://www.cs.ox.ac.uk/files/6487/pwvault.pdf" rel="nofollow">https://www.cs.ox.ac.uk/files/6487/pwvault.pdf</a>) was a good review of KeePass, Password Safe, and others. As I understood it, only Password Safe provided both secrecy and data authenticity.
What about pass (<a href="http://www.passwordstore.org/" rel="nofollow">http://www.passwordstore.org/</a>)? No "funky file formats" -- just GPG and a convenient CLI.
What about KeePassX? That's what I've been using for a long time now. It's not written in C#, but C++<p>EDIT:
source: <a href="https://github.com/keepassx/keepassx" rel="nofollow">https://github.com/keepassx/keepassx</a>
These has been a security audit, ordered by the french ANSSI (French government IT Security agency). This audit resulted in a "CSPN" certificate, which basically means that 35 days were spent by a competent auditor (Thales), and no important vulnerabilities were found in KeePass 2.0 Portable.<p>Report: <a href="http://www.ssi.gouv.fr/uploads/IMG/cspn/anssi-cspn_2010-07fr.pdf" rel="nofollow">http://www.ssi.gouv.fr/uploads/IMG/cspn/anssi-cspn_2010-07fr...</a>
To those who don't see a problem with leaking timing data:<p>KeePass goes to great lengths to do in-memory encryption of data. I'm not saying these attempts are properly done, but there is certainly no lack of trying.<p>The only reason to even bother is assume that this memory can be accessed by an attacker. So either you subscribe to that attack vector and thus must also accept the necessity of avoiding timing attacks, or you reject this threat vector and must question why KeePass engages in all kinds of memory-obfuscation security circus/theater.
Much like 4th page retractions on stories in newspapers, headlines will always win out in terms of the influence on the readers.<p>That said, the author of KeePass responded to all the discussions here over on the project forum at SourceForge.<p>Since a lot of people aren't willing to even visit SF anymore, his notable responses were:<p>The header validation was fixed as of 2.20 in 2012<p>The singleton safety he was aware of, and it was only instanced prior to any threading of the application, so there could never be a thread safety issue. He has fixed this anyhow as the performance impact was minimal as of 2.30<p>The installers available via SF mirroring are signed by the author, so SF can not ever mess with them. They have no concerns about SF doing anything to their project.
Ok, your password database was affected by malicious modification. So what? How it can break the confidentiality of your data?
Update: By the way, what's wrong with the bytearray compare code snippet?
KeePass from version 1.24 & 2.20 (in 2012) use header authentication to prevent data corruption attacks.
<a href="http://keepass.info/help/kb/sec_issues.html" rel="nofollow">http://keepass.info/help/kb/sec_issues.html</a><p>cheers, Paul
Apparently someone reported this thread to the author. You might want to follow the SourceForge issue: <a href="http://sourceforge.net/p/keepass/discussion/329220/thread/2eac8c83/" rel="nofollow">http://sourceforge.net/p/keepass/discussion/329220/thread/2e...</a>
1. It would be nice if someone like CodesInChaos (ie. someone with both crypto <i>and</i> .NET expertise) were to casually audit the KeePass 2.x codebase and do a write-up.<p>2. It would be nice to create a kdbx 3.0 (ix. next-gen) storage format, which does proper AEAD.
Additional evidence of inadequate .NET implementation:<p>There is a ton of code & pointless complexity to minimize the time sensitive data has to remain in plaintext in memory, and zeroing buffers asap. Clearly, the "process memory compromise" threat vector is taken very seriously by the authors.<p>Here's a KeePass function that generates a key:
<a href="https://github.com/wrouesnel/keepass/blob/master/KeePassLib/Keys/CompositeKey.cs#L155" rel="nofollow">https://github.com/wrouesnel/keepass/blob/master/KeePassLib/...</a><p>Does anyone see what the problem is? Hint: disposing "ms" in addition to closing will not fix the problem.<p>There are ~ 59 instances of this mistake in the codebase. The author(s) seem to come from c/c++ background, and make all kinds of assumptions about how .NET works - except that .NET doesn't work the way they think it works.<p>The generation of the Master Key:
<a href="https://github.com/wrouesnel/keepass/blob/master/KeePassLib/Keys/CompositeKey.cs#L243" rel="nofollow">https://github.com/wrouesnel/keepass/blob/master/KeePassLib/...</a><p>Note that "pbNewKey" can be sitting in memory forever.<p>TL/DR: KeePass memory protection is completely ineffective (I only speak for .NET implementation).
Thanks for your remarks on KeePass; I have at times been a heavy user. I've often wondered about its security (especially the security of its ports) but I don't have the expertise to evaluate it myself. I'm not aware of any audits or systematic analyses as it hasn't received the attention that mobile password managers have.<p>The truly paranoid keep their KeePass database in an encrypted volume used solely for that purpose.
Answering on whether somebody did an audit for KeePass
<a href="http://keepass.info/ratings.html" rel="nofollow">http://keepass.info/ratings.html</a>
I'm not sure but one may look at
<a href="https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_downloads/anwender/software/BSI-CS_003.html" rel="nofollow">https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_download...</a>
and
<a href="http://www.ssi.gouv.fr/entreprise/certification_cspn/keepass-version-2-10-portable/" rel="nofollow">http://www.ssi.gouv.fr/entreprise/certification_cspn/keepass...</a>
The author is commenting on this thread here:
<a href="http://sourceforge.net/p/keepass/discussion/329220/thread/2eac8c83/" rel="nofollow">http://sourceforge.net/p/keepass/discussion/329220/thread/2e...</a><p>The issues raised in the thread are documented on his webpage here:
<a href="http://keepass.info/help/base/security.html" rel="nofollow">http://keepass.info/help/base/security.html</a>
<a href="http://keepass.info/help/kb/sec_issues.html" rel="nofollow">http://keepass.info/help/kb/sec_issues.html</a>
For anyone who has wanted to switch to KeePassX (to avoid mono dependencies, for instance), but needed the integration with keepasshttp, this project is active: <a href="https://github.com/Ivan0xFF/keepassx" rel="nofollow">https://github.com/Ivan0xFF/keepassx</a><p>I haven't switched yet to Ivan0xFF's port yet (I've been using the auto-type based on window title). I may not actually switch, as the Pass project some others have posted here looks very good as a cross-platform solution (e.g., there is an android app and Firefox plugin) and there are scripts for converting existing databases to the new keystore.
Well it sounds like you just did a security audit of KeePass, albeit an incomplete and cursory one. But as a small open-source project, that's probably better than they have now.<p>Have you considered submitting this analysis to the KeePass team? Or even better, analysis plus suggested code to fix the problems? As a user of KeePass this would be in your interest.<p>(And as a user of KeePass myself, it is in my interest to encourage experts to help that project out.)
I have been a KeePass user for many years and I always used this in conjunction with a TrueCrypt container meaning that I keep my kdbx file inside the container.<p>Yes TrueCrypt isn't "safe" but at this point it will take one highly motivated attacker to steal my "important" passwords.<p>Sadly I am not aware of any audits related to KeePass but I would be happy to read one!
Hello!<p>Nothing about KeePass, but recently I was wondering if I could write a software for deriving the keys from the master secret and seed (i.e. domain name or whatever).<p>Here is what I have came with:<p>* <a href="https://github.com/indutny/derivepass" rel="nofollow">https://github.com/indutny/derivepass</a>
* <a href="https://github.com/indutny/scrypt" rel="nofollow">https://github.com/indutny/scrypt</a><p>It is using dump scrypt implementation (see the second link), and should be pretty easy to verify by cross-reading the source and the spec. Also, there is a boilerplate iOS application which is using `derivepass`'s derivation function and `scrypt` too.<p>Please let me know if you have any questions!
I've been working on a password manager for a while now. It's been a learning experience in practically every way. I'm not a cryptographer but needed a couple features that the other password managers dont have, and would be too difficult to patch, so I wrote my own. KeePass is really good and user friendly, but like I said, is missing some things I need.<p>It's hosted on sourceforge which I don't plan on changing since they seem to have wisened up. If you want to try it out or help with development the project page is at <a href="http://sourceforge.net/projects/pwmd/" rel="nofollow">http://sourceforge.net/projects/pwmd/</a>.
This is why for work at least, I've kept to a spreadsheet on my workstation, the workstation uses full disk encryption, so I feel this is reasonably secure. For home, I'm nearly 100% apple, so I'm using keychain.
It's better than nothing and likely better than something without source.<p>Using the CLR which has no guaranteed memory zeroing and has immutable strings and GC and an exposed profiler and debugging APi is a larger concern IMHO.
Open source, open standard, generative password manager with "two-factor" security using both a passphrase and a private key file: <a href="http://rampantlogic.com/entropass/" rel="nofollow">http://rampantlogic.com/entropass/</a><p>It only uses the industry standard pbkdf2-sha512 hashing algorithm, with no encrypted database, so it is much simpler and isn't susceptible to these kinds of issues.
Keepass was never meant for corporate use, that much I am positive about. So personally I use gpg through the pass(1) script.<p>However, for corporate use I must recommend siptrack, a Django-based webbapp with a xmlrpc gui that tries not so much to replace keepass but rather racktables and keepass.<p>So it's much more than password management but it uses pycrypto and doesn't try to re-invent encryption. Future plans have it moving to pynacl too.
From my point of view, an authenticator (e.g. HMAC) is only necessary in case of a protocol-based transmission.
-> And no, I don't mean to put the file (that is completly read first) on the dropbox.
An authentication between the main memory and the CPU is obviously not required.
Honest question. What's wrong with the function?
I have a similar function to ironically enough compare Hmacs in an encryption program I wrote in Java and C#
When I release the source code for the java version I replaced my function with java's own Arrays.equals though
What about KeePass 1.x?<p>And considering you can freely copy the database and someone corrupting your own is "only" going to result in you not being able to login, is that really a threat model that is more important with just encrypting everything so they can't be read?
What are the alternatives really? I'd love to get rid of KeePass, it's GUI is awful, it really doesn't support OS X (unless some really technical person installs it). I'm unwilling to use commercial closed, cloud based password databases.
It is so annoying. It must be something you know (Passcode), you are (Iris) or something you have (Key).<p>In case of Passwords, it is something you know. With limitations to the site (at least X Characters, small and capital, one number but not at the beginning, no number at the end, at least one special...). Some Banking sites even only allow a scary limited amount of characters (I think Schwab allows only 7 and no special characters).<p>Regarding a PW Manager: I found them all annoying and one has corrupted the PW database several times, resulting in a loss of the passwords.<p>My solution: A plain textfile with all my passwords.
(I use Linux with an encrypted partition). If this is not secure enough for you, encrypt it with GPG.