#2166 Digitally Sign KeePass.config.xml

[forge-it-k]

If you have write access to the configuration file, it seems fairly trivial to add a trigger to dump the database to a file. I know the argument is that if people can access your machine/profile, it is not secure anyway. But if this were all there was to it, I would simply use a spreadsheet to store passwords.

Perhaps if a digital signature were added to to the config file (https://msdn.microsoft.com/en-us/library/ms229745(v=vs.110).aspx), this vulnerablility could be avoided as any monkeying with this file outside of the keypass gui would be detected.

[Dominik Reichl]

In order to digitally sign the configuration file, the private key of a certificate is required. Where does the certificate come from?

The certificate cannot be built-in to KeePass, because then it would be public and an attacker can simply use it himself. Actually, wherever KeePass loads the certificate from: if you run malware with the same rights as KeePass, the malware can obtain the certificate from the same location (as it has the same rights). Encrypting the configuration using the current Windows user credentials also won't help (because malware running as the same user can simply decrypt it, too).

Also see http://keepass.info/help/base/security.html#secspecattacks .

You could always run KeePass as administrator and ensure that only the administrator has write access to the application and application data directory. When running malware with normal user rights only, it won't be able to modify the configuration file. However, always running an application as administrator in general is not a good idea; for example, some plugins may not work like this (for instance I can imagine that integration plugins between KeePass and applications running with normal rights cannot communicate anymore).

Best regards,
Dominik

[forge-it-k]

Thank you for your reply Dominik. I did read that link before posting.

I know your question is rhetorical but:

Where does the certificate come from?
If it must be truly private, perhaps a web service could do the signing when the configuration changes, not that I am suggesting this.

I'm not really talking about sophisticated malware running on a compromised machine – not keyloggers, dll injection, binary replacement or anything.

An example, here at work, the domain administrator has access to the file systems and can edit the config. No issue with an admin running using my credentials as they do not know them. But a simple matter to update the config to dump the contents of my db when I open it by editing the file from the default share. I think my kids at home sharing my profile could open up keypass without opening a database, set up a trigger to dump the database next time I open my db, without me knowing.

I am no expert, but I would think that if you can encrypt a password file, it would be possible to encrypt at least the Triggers configuration should there be any. The same approach could be taken (require password). Upon first execution of a trigger, the user could be prompted provide the password.

Perhaps an even simpler approach (perhaps another feature request suggested, but denied??), would be to have the kdbx database contain a setting (UUID of an entry perhaps) and prompt for the password upon executing compromising trigger actions against it. It could be entirely optional and the app could behave the same if this password was not there.

I think Google made the same arguments with their password manager in Chrome that if your profile is compromised any further encryption is useless. Firefox on the other hand did have a secondary level of encryption via the master password. I continued using Firefox for a long time for that reason. Then I discovered Keypass and thought I could have the best of both worlds (and synchronization – really cool). But I am a little shocked after discovered the ease at which my database can be dumped to plain text without my knowledge given the environments which I use.

Thanks you for an awesome product BTW!

[Paul]

The problem with an encrypted config is it's read at KeePass startup, not atfter database open, so you would need a key that is available to KeePass to use on that specific config file. The only place I can see that you could store the key is with the config file and that's pointless. Basically, whatever method you use to secure the config file is vulnerable to simple attack so you gain no additional security. Physical security is king here.

cheers, Paul

[Dominik Reichl]

I agree with Paul. In order to protect the configuration file, we'd need another key. If you're willing to enter another key for decrypting/verifying the configuration file, you could alternatively put a portable KeePass into a TrueCrypt container for example.

For domain administrators, there are easier ways to steal data than to inject malicious triggers. For example, a domain administrator could simply create a logon script that runs a keylogger or other spyware on your machine, or replace the KeePass executable with a maliciously modified one, etc. Instead of a logon script, he could put malware into your start menu autostart folder (in your profile), add an autorun in your registry, and so on; there are many possibilities. In general, everyone who has write access to your user profile can also make you run malware; there's nothing special about triggers.

Best regards,
Dominik