#1427 Lock Workspace doesn't lock options from systray

[Dave Merrick]

I just noticed a huge comprimise to security in 2.3 under windows 10.

If you lock the workspace, you can still access the "options" menu from the systray icon.
This would allow an unauthorized user to change the lock workspace behavior.
A user's passwords could easily be comprimised without even knowing it, after the next unlock.

[wellread1]

By design, Workspace settings can be changed anytime the KeePass Workspace (keepass.exe) is running and become effective immediately (except for policy settings which beome effective at the next KeePass startup).

To lockdown Workspace settings, create an Enforced Configuration file in the KeePass program directory that contains the settings that you wish to lock down (the keepass.config.enforced.xml file has the same structure and format as the standard config file: keepass.config.xml) and make sure that the KeePass program directory is Read Only for the current user (i.e. requires elevated privledges to edit). Enforced Configuration is described at http://keepass.info/help/base/configuration.html.

Enforced settings will be grayed out and cannot be changed from the Workspace.

[Paul]

This has always been possible in KeePass V2.

In what way can passwords be compromised using this method?

cheers, Paul

[Dominik Reichl]

This behavior is intended and does not affect security.

Best regards,
Dominik

[Dave Merrick]

Thanks for closing the ticket before I could respond....
Here's the scenario:

1) I have my security set to automatically lock the workspace on minimize.
2) I walk away from my desk.
3) "bad guy" right clicks on systray icon and changes is so that the workspace doesn't lock on minimise or timeout.
4) Later when I unlock the workspace, I minimize it to the tray thinking it's locked. IT'S NOT.
5) "bad guy" comes along and has full access to all my passwords.

I'm sorry, but I don't see how you can consider this not a huge security hole. You should not be able to change the lockdown behavior while it's in lockdown. That's just stupid.

[wellread1]

It is your responsibility to protect your computer from unauthorized access by using methods that are appropriate to the enviornment you are operating in. If you choose to operate your computer in a manner that allows malicous access to it, any number of important settings can be changed. These include KeePass settings, regardless of whether KeePass is running or not. However, in the case of KeePass, the feature I described above can help... if you choose to implement it.

[T. Bug Reporter]

I never use the "minimize to tray" option, but it looks like the type of attack the OP is envisioning would be thwarted by creating a KeePass.config.enforced.xml file with the following contents:

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Security>
        <WorkspaceLocking>
            <LockOnWindowMinimize>true</LockOnWindowMinimize>
        </WorkspaceLocking>
    </Security>
</Configuration>

(I've become something of an expert on the KeePass.config.enforced.xml file, because of other design decisions that I consider equally dubious. I would also go so far as to say that the KeePass.config.enforced.xml file should also include these clauses...)

    <Security>
        <Policy>
            <ChangeMasterKeyNoKey>false</ChangeMasterKeyNoKey>
        </Policy>
    </Security>

(Without this, KeePass would allow drive-by vandals to change the master key to your database without first asking for the existing key.)

    <Defaults>
        <RememberKeySources>false</RememberKeySources>
    </Defaults>

(This forces KeePass to forget whether your database requires a key file as part of its master password. The program author has repeatedly stressed that it's not the existence or location of a key file that needs to be kept secret, it's the contents - but I think that revealing the location to any Nosy Nellie who happens by when you're not paying attention could go a long way toward enabling Nellie to obtain the file in question, and thereby its contents.)

To summarize, I do think that the OP has a point, in that average KeePass users shouldn't have to muck with XML files in order to protect themselves from simple attacks like these.

---

It is your responsibility to protect your computer from unauthorized access

Computer programs can be made in ways that minimize the damage when we drop the ball - and we will drop the ball sometimes. Nobody's perfect.

[Dominik Reichl]

If the options dialog would be disabled in locked state, multiple problems arise. For example, it would be too easy for users to lock themselves out: specify 1 second as locking timeout (or any combination of locking options that results in the workspace being locked all the time) and click [OK]; the only way to undo this would be to delete or edit the XML configuration file, which many users won't be able to do.

Disabling the options dialog in locked state does not improve security. If you leave your computer unlocked, an attacker could simply edit the XML configuration file (and editing an XML file is not expert knowledge; I do not consider this as an effective security layer against "average" attackers). Like Wellread1 said, the user is responsible to protect the computer from unauthorized access.

I recommend the solution that Wellread1 described.

Best regards,
Dominik

[T. Bug Reporter]

For future reference, here is an example of a person who apparently locked himself out of his KeePass installation in exactly the manner Dominik described above. However, I still think that this situation is rare enough that it could be handled with a brief tutorial on resetting one's installation by removing the existing configuration file instead of allowing changes to the configuration from the program without entering a password.

[Dave Merrick]

It just seems to me that the solution would be to not allow the timeout to go below a certian time.
I may be mistaken, but the program is designed for human interaction, and isn't normally being called by an API from another program.

I do realize that everyone types at different speeds and has different human-machine interaction speeds, but the way it's implemented, it really seems like a kludge.
I'd be curious who it hurts if the program couldn't lockdown faster than in , say, 10 seconds. (I'm not trying to sound mean/angy or pick a fight, I would just honestly like to be educated on what part of the picture I'm missing)

[Paul]

There are several plug-ins that mean you almost never need to open KeePass manually, so a very short timeout is valid, but a warning when you set a very short timeout would be of value.

cheers, Paul