Thomas J Howard

Very happy to see this fixed. Thank You @dreichl for listening. As to what some wrote about the prompt - yes, it could have been better designed, as the PEBKAC is a real and grave problem, some say that even unsolvable, but at the same time, this is a completely different issue. Both wider and with different implications. It is not a vulnerability per se, just a design choice. I do not think that we should debate this one in this thread.

The fact that the software is secure (or not in this instance) by default is huge factor in recommending such software to other users. There are huge numbers of users that are not technical enough, or not competent enough to understand the threat landscape, but could still greatly benefit from using a secure password manager. You simply cannot expect such users to read technical documentation for software, to find out how many vulnerabilities it have and fixing those themselves. And this applies...

I am not sure which posts you are refering to, but I would like to point out that this debate is not about the enforced configuration file or its protection (which I think most if not all acknowledge as adequate). It is instead about the regular user-owned config file, which does not require administrative-level permissions to modify, as this is the default configuration the software is delivered with. Ability to mitigate this issue by using enforced config does not change the fact that the software...

This is not exactly the case. First of all, attacker having capability to execute code is vastly different from attacker being able to replace existing code. Replacing binaries or any other part of "core" KeePass software is very different as well. Being able to execute code with the privileges of current user does not automatically grant you the ability to see inside his KeePass database, while it most likely gives you ability to modify a "regular" user-owned file such as KeePass user config. Two...

I fully understand that enforcing the configuration is possible and that it can have pretty much the same protections as the binary can. That is all fine and appreciated, but it not the main point here. Security is a game of cost effectiveness and resource allocation. We can make systems extremely secure, but at the same time, no business is interested in such costs (no government either). IT Administrators are usually overburdened with tasks and responsibilities while not being paid adequately....

I fully understand that enforcing the configuration is possible and that it can have pretty much the same protections as the binary can. That is all fine and appreciated, but it not the main point here. Security is a game of cost effectiveness and resource allocation. We can make systems extremely secure, but at the same time, no business is interested in such costs (no government either). IT Administrators are usually overburdened with tasks and responsibilities while not being paid adequately....

The actual security landscape is much more complex than just the range of technically possible attacks. There are quite many scenarios mentioned in this thread and it is very hard to discuss them all in fine detail, but I wanted to point out couple things. First, the obvious. There is a huge difference between an attacker having to modify one XML config file in users profile, and modifying any OS files, injecting DLLs, reading process memory, etc. The fact that he might be able to does not mean that...

The actual security landscape is much more than just what attacks are technically possible. There are quite many scenarios mentioned in this thread and it is very hard to discuss them all in fine detail, but I wanted to point out couple things. First, the obvious. There is a huge difference between an attacker having to modify one XML config file in users profile, and modifying any OS files, injecting DLLs, reading process memory, etc. The fact that he might be able to does not mean that it is a...