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

31–40 of 231 posts

Re: KeePass – questionable security

#31

Post by sdrapkin »

philbarr wrote: post #19
sdrapkin wrote: post #16

Earlier quoted context omitted.

Any takers on that question?

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?

Re: KeePass – questionable security

#32

Post by jfreax »

xenophonf wrote: post #24
FractalNerve wrote: post #2

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.

Just a general info: KeePassX can read and write the KeePass2 file format, but you have to checkout the git repo manually. It works for me since at least one year.

The problem is the current maintainer, it seems that he has no interest in releasing a new version :(

Re: KeePass – questionable security

#33

Post by jokamoto »

justizin wrote: post #9
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 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.

If the attacker already has control of the email address, they can reset the account without going to such lengths--just visit the site and request a password reset.

Re: KeePass – questionable security

#34

Post by sdrapkin »

StavrosK wrote: post #27
sdrapkin wrote: post #13

Earlier quoted context omitted.

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…

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.

Re: KeePass – questionable security

#36

Post by xenophonf »

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?

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 a user
  alters, and then saves, a corrupted database, all
  passwords previously affected by the attack are lost
  forever.

  This attack highlights a remarkable design flaw. Even
  an accidental bit-flip in the *pskey* field, e.g., due
  to a transmission error, cannot be detected, and leads
  to complete corruption of the database. Such
  corruption is unlikely to be immediately detected by
  users, who may subsequently add new entries. Over time,
  the database will be composed of both correct and
  corrupted entries, making it difficult to reconstruct
  the damaged records from a backup.
Which reminds me - I need to migrate back to Password Safe as soon as possible.

Re: KeePass – questionable security

#37

Post by AjithAntony »

StavrosK wrote: post #27
sdrapkin wrote: post #13

Earlier quoted context omitted.

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…

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?

I think he's suggesting that you happen to actually know the right password, and will attempt to enter it after the failed keepass attempt? But then, if you know the right password, you could also visually inspect the keepass data to know it was wrong.

Re: KeePass – questionable security

#38

Post by mc808 »

jarito wrote: post #22
sdrapkin wrote: post #16

Earlier quoted context omitted.

Any takers on that question?

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...).

Re: KeePass – questionable security

#39

Post by negus »

xenophonf wrote: post #36
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?

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.
Post reply on HN