Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

KeePass – questionable security

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 231 posts

Re: KeePass – questionable security

#71

Post by ifdefdebug »

sdrapkin wrote: post #55
ifdefdebug wrote: post #43

Earlier quoted context omitted.

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.

I have verified that the CryptoRandom class is part of a standalone library with (1) should be thread-safe since it cannot dictate how it will be used by callers; (2) the authors clearly intended this library to be thread-safe (based on "thread-safe" comments in its source code). And in all likelihood it is thread-safe - but that's due to being lucky - not competent. The larger issue is that we have a widely-used cry…

Well, "(1) should be thread-safe since it cannot dictate how it will be used by callers" doesn't hold. For instance most of .NET classes are not thread-safe because thread-safety has a cost. So it's a question of documentation (it's well documented in .NET).

But "(2) the authors clearly intended this library to be thread-safe" means that piece of code is bad. So you have a point here.

Re: KeePass – questionable security

#72

Post by mey »

tptacek wrote: post #61

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. To the many readers of this thread who believe they don't care about the integrity of their password vault, just its confidentiality: The problem is you can't…

Considering your background and experience, do you have a recommendation for personal level password management?

Re: KeePass – questionable security

#73

Post by Tomte »

gnud wrote: post #45
Tomte wrote: post #14

Earlier quoted context omitted.

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.

I must admit, I can't immediately see the problem with leaking timing data. 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.

Me neither, I just tried to explain what the other poster /probably/ meant.

Re: KeePass – questionable security

#74

Post by cmdrfred »

sdrapkin wrote: post #13
negus wrote: post #4

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 notice that the "change-password" function of yourbank.com is accidentally being served over HTTP instead of HTTPS. I just need to trick you into changing your password. 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 passwor…

I have a private server in a datacenter that I put together myself. I use sftp to download/upload my keepass file, I also use a keyfile that stays local and a password for auth. What is the attack vector there?

Re: KeePass – questionable security

#75

Post by mhomde »

ifdefdebug wrote: post #43
sdrapkin wrote: post #31

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.

The odds of an singleton being called for the first time simultaneously is abysmal. Usually you even call a singleton first in your own initialization code making errors impossible.

I do agree that technically you are correct and you should wear belt and suspenders, especially if it's a library for third-party consumption and labeled as thread-safe... but still... its pretty esoteric, and only used by the author (I assume) who knows its not thread-safe. Locking isn't exactly without its performance implications either and even though that is neglible it feels unecessary if a race condition is de facto near impossible.

Re: KeePass – questionable security

#76

Post by tptacek »

mey wrote: post #72
tptacek wrote: post #61

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. To the many readers of this thread who believe they don't care about the integrity of their password vault, just its confidentiality: The problem is you can't…

Considering your background and experience, do you have a recommendation for personal level password management?

I use and like 1Password.

Re: KeePass – questionable security

#77

Post by tetraodonpuffer »

jgrowl wrote: post #46
anewhnaccount wrote: post #35

http://www.passwordstore.org/

It may not be as polished as some of the other options out there, but it is what I use. I am mostly happy with it. I just wish there was a built in way to encrypt the folder structure to hide what sites I have credentials for.

not built in but if you're on linux you can always overlay ecryptfs on your password safe directory, or just have your passwords in a separate vm entirely that is used only for that

Re: KeePass – questionable security

#78

Post by sdrapkin »

To those who don't see a problem with leaking timing data:

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.

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.

Re: KeePass – questionable security

#79

Post by jgrowl »

tetraodonpuffer wrote: post #77
jgrowl wrote: post #46

Earlier quoted context omitted.

It may not be as polished as some of the other options out there, but it is what I use. I am mostly happy with it. I just wish there was a built in way to encrypt the folder structure to hide what sites I have credentials for.

not built in but if you're on linux you can always overlay ecryptfs on your password safe directory, or just have your passwords in a separate vm entirely that is used only for that

Good points. I've just been too lazy to encrypt the directory myself.

Running a separate vm is an interesting idea that I had not thought of.

Re: KeePass – questionable security

#80

Post by Guillaume86 »

wumbernang wrote: post #5

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.

I didn't check but I assume they use SecureString.
Post reply on HN