On the Security of Password Manager Database Formats (2012) [pdf] | Hacker News Reader

On the Security of Password Manager Database Formats (2012) [pdf]

cs.ox.ac.uk

69 pointsmonort20 comments

http://keepass.info/help/kb/sec_issues.html

Problem. In their paper 'On The Security of Password Manager Database Formats', P. Gasti and K. B. Rasmussen have presented attacks on the KDB and KDBX file formats based on unauthenticated header data. For KDB, this issue has allowed silent data removal attacks. For KDBX, the issue has allowed silent data corruption attacks. Both were minor security issues (confidentiality was not compromised).

Status. Header data authentication has been introduced for both KDB and KDBX in KeePass 1.24 and 2.20, in order to prevent the attacks. Also see the release notes KeePass 1.24 and 2.20 Header Authentication. P. Gasti and K. B. Rasmussen published their paper in a responsible disclosure process, and the defenses in KeePass have been implemented before the issues were presented to the public.

It there a similar study done more recently on this exact topic? Would love to know if the problems revealed in this paper have been fixed in 1Password and others

They've definitely been fixed in 1Password. I think they were fixed in the next version after the paper. They've discussed it pretty openly on their blog, but it was shortly after the paper was released and that's been a few years.

For the record, KeePass added header authentication after (thanks to) this paper.

More details here:

http://keepass.info/help/kb/db_headerauth_upg.html

Also, Dominik responded to claims made in a (unfounded) post here: https://news.ycombinator.com/item?id=9727297 with a quick blurb: http://keepass.info/help/kb/sec_issues.html

I think KeePass with the key file option (not readable by user accounts, run KP as admin) is the best solution on Windows I've found.

A pity it doesn't include analysis of using gpg-encrypted file (pwd.sh/passbox-style) or files (pass-style).

I've been using Password Safe for years. Nice to see verification that it is as secure as I thought it was.

This paper appears to precede the rise of LastPass. I'd be curious how it stacks against the rest of them.

LastPass got hacked just this year:

http://lifehacker.com/lastpass-hacked-time-to-change-your-ma...

I'm new to infosec and I'm having a bit of trouble understanding how PasswordSafe is able to modify the master password without re-encrypting the entire database with the new salt.

The only scenario I see this happening is if, upon the creation of a new master password, PasswordSafe encrypts the header (with the old password). This way, when the user enters their new password, PS uses it to decrypt the header, and then uses the old password (stored in the header) to decrypt the database. This would make it easy for someone with access to the old password and the database to simply decrypt it.

Is this how it works? I can't think of any other way it would be able to not re-encrypt the database with the new password. Plus the lingo/acronyms in the paper are going a bit over my head.

Generally these things work by creating a master key to encrypt the data. The master key is then encrypted with a key derived from the password. To change the password the master key just needs to be reencrypted.

This is correct. For v3, with P' the key derived from stretching the password:

"2.6 B1 and B2 are two 128-bit blocks encrypted with Twofish [TWOFISH] using P' as the key, in ECB mode. These blocks contain the 256 bit random key K that is used to encrypt the actual records. (This has the property that there is no known or guessable information on the plaintext encrypted with the passphrase-derived key that allows an attacker to mount an attack that bypasses the key stretching algorithm.)"

Bruce Schneier's PasswordSafe (according to this paper the safest of all those considered):

http://passwordsafe.sourceforge.net/

Available for:

- Windows

- Linux

- Android

Works pretty well under Wine on Mac OS X too. (Very sporadically, it locks up for me; probably Wine's fault.)

> Google Chrome stores usernames and passwords in an SQLite database file in the user profile directory. This database provides neither secrecy nor integrity.

Chrome has since implemented OS-level security, the SQLite database contains ciphertext instead of plain passwords.

Is this encryption directly related to my Windows password? Can I transfer the "Login Data" database to another PC with the same password? Or is my password only a passphrase for a longer key?

I think it's a huge shame that Chrome has moved away from integrating with the OSX keychain / Keychain Access since v45. Apparently they argued Safari used the keychain in such a way that passwords weren't shared with other apps, so why should Chrome :-/

Of course, the real reason is that Chrome is an OS masquerading as a browser. If you consider the keychain to be an OS level function, Chrome (the OS) provides it.

>Unfortunately, most formats turned out to be broken even against very weak adversaries. For this reason, users should carefully consider whether a particular database format is acceptable for storing data in the cloud, on a USB drive or on a machine shared with other users.

Finally, our works shows that it is indeed possible to construct a format that provides security, usability and low computation and storage overhead, using standard cryptographic tools.

Can you explain?

Reply on news.ycombinator.com