4 ms·

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 passwor

• coding123 4y ago
  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?
  • vgalin 4y ago
    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.
    • usrusr 4y ago
      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.
      • jonathanstrange 4y ago
        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.
• 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".
• vgalin 4y ago
  The export would only be triggered when a database is opened, so the master password is required.