(preambel, forum search seems to be unavailable at the moment, "[Errno 111] Connection refused" - sorry if this topic should have been discussed before)
Problem: there are useful options to auto-lock an inactive workspace after a certain time. However, these options are ineffective while an entry dialog is open. In other words: The whole DB remains in unlocked state allover the time if the user forgets to close an entry dialog before. I think this is a severe security risk! (...and I struggled already many times in this trap)
Proposal: Add the following options on the keepass options dialog, tab 'Security':
[ ] Auto-close entry after user inactivity (seconds) __
(x) Auto-confirm modified entry when closing it
( ) Cancel modified entry when closing it
Legend: [ ] demarks a checkbox, ( ) demarks a radio button, __ demarks an entry or spinner field
...or even simpler (because nobody wants to auto-cancel a modified entry:
[ ] Auto-close and confirm an open entry dialog after user inactivity (seconds) _
This request affects KeePass 2.x
See the technical FAQ: Why doesn't KeePass lock when Windows locks and a KeePass sub-dialog is open? for why this won't be implemented. There are three alternatives that I can think of:
Edit: fixed incorrect link to FAQ
Which means the KeePass behaviour is not going to change, despite numerous requests.
I was thinking along the same lines. I sometimes leave keypass open and it would be great if keypass would lock itself i.e. force a re-enter the password for the open file) after an inactivity timeout. Yes I'm stupid to walk away from my PC without locking it or having a screen saver kick in etc... but it doesn't mean I should lose my most secret data because of keypass is only paranoid and not super super paranoid about protecting that extremely important data vs I really don't give a fig if someone starts playing around with my unlocked PC. I vote for a 'lock keypass after inactivity timeout' feature.
This should really be re-examined. The failure to lock after while a dialog is open is a huge security hole, defeating everything else in the program.
An alternative view is that the behavior is simple program behavior that reflects best practice. Editing an entry should not be viewed as a casual activity that can be interrupted. KeePass allows the user to abort the edit, or complete the edit. Intermediate behavior creates a more complicated decision tree that is more error prone.
If you would like the ability to edit at will without inhibiting the KeePass locking routine, the KPEnhancedEntryView plugin offers an excellent solution for most entry editing tasks. I use this plugin and like it quite a lot.