41–50 of 231 posts
And I thought I was safe using Keepass on Dropbox. Any recommendations for password managing?
Earlier quoted context omitted.
I assume that they are implying that the code is not constant time. In this snippet, the code bails as soon as a deviation is detected. This can, in theory, allow an attacker to determine the desired value by measuring the time taken to reject incorrect options. I haven't reviewed the code to see if this is actually a problem, but that's my guess for why it was highlighted.
I took it to mean they should use the Linq `x.SequenceEqual(y)` instead (assuming .NET 3.5+) (and x isn't null...).
Earlier quoted context omitted.
Well, it's not thread safe but they might not think that's an issue. It looks like this: 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; } }
Philbarr is correct. The pattern they are using is fundamentally supposed to provide a thread-safe Singleton, and it fails to do that. Is that a security problem in this specific context? No. But it's a "No" because the authors are lucky in this case - not because they are competent. Now, that's just one instance of poor skill. There are many more. Are you sure none of them have security implications?
"On The Security of Password Manager Database Formats" ( https://www.cs.ox.ac.uk/files/6487/pwvault.pdf ) was a good review of KeePass, Password Safe, and others. As I understood it, only Password Safe provided both secrecy and data authenticity.
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?
The array comparison? It's literally the textbook example of a timing sidechannel. Though I won't speculate if it's a real problem here, since I have no idea what data is being compared.
The client (that decrypts the password database) runs on your local computer, and typically places clear-text-passwords into the clipboard during normal use. So if your local computer is compromised you have way bigger problems than timing attacks.
http://www.passwordstore.org/
I just wish there was a built in way to encrypt the folder structure to hide what sites I have credentials for.
Earlier quoted context omitted.
Wait, you just inserted an invalid password in my database, how do I change my password? Hell, the only way I'll even realize something's wrong is by trying to log in in the first place, and, if you can see my connection, why would you have me enter a wrong password, rather than the right one?
Because the main login is HTTPS-secure (I would hope - for a bank), but the change-password feature is not.
What about KeePassX? That's what I've been using for a long time now. It's not written in C#, but C++ EDIT: source: https://github.com/keepassx/keepassx
KeePassX uses an older database format (KDB) than KeePass 2.x (KDBX4). It also lacks AEAD and is actually less secure than KDBX4 according to the analyses I've read.
Edit: it is available as a Mac binary on the KeePassX site.
Earlier quoted context omitted.
Philbarr is correct. The pattern they are using is fundamentally supposed to provide a thread-safe Singleton, and it fails to do that. Is that a security problem in this specific context? No. But it's a "No" because the authors are lucky in this case - not because they are competent. Now, that's just one instance of poor skill. There are many more. Are you sure none of them have security implications?
That's quite harsh. I guess you verified that there are actually different threads able to access this code before making such a statement? For instance, if I make a single-threaded application in the first place then I don't care about thread-safety at all. Because I am not going to need it.
public ulong GeneratedBytesCount
{
get
{
ulong u;
lock(m_oSyncRoot) { u = m_uGeneratedBytesCount; }
return u;
}
}
Earlier quoted context omitted.
Confidentiality isn't your only concern. You should also be worried about integrity and availability. From "On The Security of Password Manager Database Formats": Unfortunately, [KDBX4] introduces new vulnerabilities. Similarly to KDB, the main problem of this format is the lack of authentication of *hdr*. As such, is it susceptible to modifications... This modification is not detectable by the password manager... if…
Confidentiality is my only concern in the case of malicious modification. Remember, that availability and integrity of your database can be broken without an attacker, just due to hardware problem, for example. So it is up to you to have a cold backup for such a critical asset.
Over time, the database will be composed of both
correct and corrupted entries, making it difficult
to reconstruct the damaged records from a backup.