5 ms·

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

by gnud 4y ago

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

jonathanstrange 4y ago
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.
- deleted 4y ago
  [deleted]
gnud 4y ago
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....
- jonathanstrange 4y ago
  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.
  - notRobot 4y ago
    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.
friendzis 4y ago
> 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".

by gnud 4y ago

jonathanstrange 4y ago

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.

deleted 4y ago
[deleted]

gnud 4y ago

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

jonathanstrange 4y ago
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.
- notRobot 4y ago
  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.

friendzis 4y ago

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