[Feature Request] Separate timeout for browser integration

[aksh1618]

As @Vilx2 said in #2569:

My main issue is that I don't want to keep my database unlocked at all times. Password managers are there to be secure, but it kinda defeats the purpose if anyone who can walk by my computer can also quickly take a glance at all my passwords.

This is my major pain point with keepassxc. With browser's saved passwords, someone has to at least go to the relevant section and maybe even enter a password to see any saved passwords. With keepassxc, though, they just have only to go to the keepassxc window and see any password they want. To avoid this we can set up a timeout, but then the extension loses access to the db too as soon as it expires.

Expected Behavior

A separate (longer) timeout can be set for the browser integration, after which the db is locked for the extension as well. This prevents access to the db from application, but auto-filling can continue to take place in the browser through the extension.

Current Behavior

There's a single timeout after which both the desktop client and the extension lose access to the db.

Possible Solution

If not a separate timeout, maybe other ways could be adopted for more security, such as needing to enter the master password again before being able to see any passwords (the 'eye' button) or even editing an entry in the desktop client.

[droidmonkey]

This does not support security, in fact it is obscurity. The locking of the database is a very deliberate, very permanent action. It destroys all data in memory associated with the database and replaces it with a blank database object. Doing a "soft lock" which only obscures the GUI portion is not in line with the philosophy of this project and I strongly object to it.

If someone has access to your computer such that they can manipulate KeePassXC and see your passwords then nothing is stopping them from doing other actions to compromise your soft-locked database. Lock your computer and setup KeePassXC to lock on screen lock.

[aksh1618]

@droidmonkey How about a separate timeout? Or a simple, optional numeric code for seeing/editing entries? Or some other way to run the app in background (i.e. not easily accessible by the DE)?

Of course these won't act as very strict security measures, but could be good enough deterrents. I wouldn't have opened this issue if I hadn't felt such a need. Feel free to close if none of these options fit the philosophy of the project.

[droidmonkey]

We have a feature request for quick unlock which I endorse. This is similar to the numerical code and does not violate the security model. For all intents and purposes, when the app is in the system tray it is "running in the background".

[droidmonkey]

Quick unlock is #488. I am closing this issue since it will not be implemented as suggested. You can also see #1809 for more discussion.