11–20 of 231 posts
It's better than nothing and likely better than something without source. 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.
There are real issues with a false sense of security that you're glossing over here...
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?
I have access to your kdbx db (ex. you sync to Dropbox and I'm Dropbox employee). I can alter the kdbx file to change your password so that it is no longer valid. KeePass doesn't complain at all.
You have a WTF moment and try to change your password over HTTP, while I inspect network packets and grab your new password.
You say "this is far-fetched, non-realistic scenario". I say "this is poor crypto design".
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?
Though I won't speculate if it's a real problem here, since I have no idea what data is being compared.
Earlier quoted context omitted.
Well, the language isn't really in question here -- it's the crypto used for the database files themselves. KeePassX is the old database format and KeePass 2.x+ uses a newer one. I don't know if the database format also resulted in any crypto changes.
There are 2 problems here. (1) The c# .NET implementation is lacking; (2) the fundamental crypto design of the kdbx database (which is shared by all implementations, in any language) is lacking.
The safety of your database in a world where your keepass database is leaked due to a Dropbox attack or something is what really matters here, IMO.
Did they screw up the crypto so offline attacks are easier?
what is the problem with the singleton?
Yes TrueCrypt isn't "safe" but at this point it will take one highly motivated attacker to steal my "important" passwords.
Sadly I am not aware of any audits related to KeePass but I would be happy to read one!
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?
I broke into your e-mail and need to get you to force a password reset on some other account, so I maliciously modify to give you an invalid stored password.
what is the problem with the singleton?
Any takers on that question?
private static CryptoRandom m_pInstance = null;
public static CryptoRandom Instance
{
get
{
if(m_pInstance != null) return m_pInstance;
m_pInstance = new CryptoRandom();
return m_pInstance;
}
}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. Yes TrueCrypt isn't "safe" but at this point it will take one highly motivated attacker to steal my "important" passwords. Sadly I am not aware of any audits related to KeePass but I would be happy to read one!