Hacker News Reader

Comment by _puk | Hacker News Reader

Am I reading that right, that if you point Keepass.exe at any .kdbx and simply add an export option to the XML config it'll export it without the master password?

Granted you need local access to modify the config, but generally the .kdbx is stored (securely) on some shared environment. Grabbing that would mean you could export passwords at your leisure in this setup?

View on HN

As I understand it, if you modify the xml, Keepass will silently export entries in the database once you load it (by providing the password).

Keepass will (by default) not ask for the password a second time before exporting - but you have to decrypt the database once before it can be exported.

So this is not a risk if your threat model is "attacker obtains a copy of my .kdbx", but it is a risk if your threat model is "attacker can modify .kdbx without me noticing, and can access my local computer or a mounted network disk to read the exported passwords".

The point is that the password manager application ought to allow a configuration change which affects document X's plaintext only after the master passphrase has been entered by the user for document X. It's not hard to implement that for configuration files and plugins in a multi-document setting, you just need to store suitable authorization secrets in the documents. In a single-document application it's more trivial, of course, you'd encrypt the configuration file and plugins with keys derived from the master passphrase or check their signatures.

It's actually less of a risk than I thought, because the configuration is on your local install of KeePass, not in the database file.

If an attacker can modify your local install, you've lost anyway....

You have to think about security as being layered. There is a huge difference between creating a mock copy of an application or injecting code into an existing binary, and toggling a setting in a human-readable XML configuration file. Most operating systems also monitor executables more carefully than document files.

My understanding is that the attacker doesn't need to inject code, they can simply take screenshots or recordings programmatically and when that shows the password manager all passwords are exposed.

> So this is not a risk if your threat model is "attacker obtains a copy of my .kdbx", but it is a risk if your threat model is "attacker can modify .kdbx without me noticing, and can access my local computer or a mounted network disk to read the exported passwords".

No, the threat model is "the attacker can modify config file", which for default installation also means "the attacker can modify the executable".

The export would only be triggered when a database is opened, so the master password is required.

So this makes no sense. Someone that works at Dropbox has access to millions of kdbx files, and doesn't need any master passwords, just their own copy of keepass.exe?

To perform an export of a KeePass database, the database needs to be opened using (at least) a master password. A database file without its master password is still worthless on its own.

But you don't know that you are entering the password to release all your passwords into cleartext, all you wanted to do is check wether your farmville cows still exist.

That's my biggest quirk. There shouldn't be any way to export plaintext data without explicit user feedback and confirmation in the first place. That this is triggered by an unprotected global configuration file is just the icing on the cake.

Reply on news.ycombinator.com