Entering hibernation mode should have the vault already locked. As per this article from a german computer magazine, an unlocked vault keeps the master password in memory at several locations in clear text.
Hibernation would cause this clear text to be saved to disk in the hibernation file. Probably also with Windows fast start mode, which is partially hibernation.
Feature function
What will this feature do differently?
Locking the vault if hibernation/shutdown is initiated.
What benefits will this feature bring?
Remember to add a tag for each client application that will be affected
Better safety against master password leaking
Related topics + references
Are there any related topics that may help explain the need and function of this feature?
Are there any references to this feature or function on other platforms that may be helpful?
Keepass has such a feature. Its called “lock workspace if computer is about to be suspended”. While this seems to exist in the Windows App, it does not exist with the browser plugins.
Keepass Browser plugins are dependent on the desktop app, so is no issue there.
Getting notified of lock/hibernate/suspend in an extension is tricky. This is especially the case without a service running on the computer too.
There might be good news as both Firefox and Chrome have an idle API which can let an extension know if the computer’s state changes between active/idle/locked.
According to the documentation, the state changes to locked when a lockscreen or screensaver is displayed. Whether the state changes to locked when hibernating/suspending I do not know but it could be assumed. It might be exactly what’s needed to implement this feature.
It is fairly easy to asynchronously notify processes that care that a power mode event has happened.
It is much more difficult to provide a reliable way for any process to perform some task which is guaranteed to happen before a power mode change. The issue is that to guarantee this kind of result, the OS has to wait for processes to complete their task prior to the power mode change. If it does not wait, then there is no guarantee that the tasks are performed before the power mode change. But waiting for a task to complete causes more complications. Some tasks may never complete (e.g. while (true) {}). If a task crashes, what is the proper response: abort the power mode change so the user can take action, go ahead anyway (but violate the guarantee that was given), something else?
I’ve looked at Keepass’ code and sees that it hooks into SystemEvents.PowerModeChanged but I don’t see in the documentation of this event any guarantees as to the timeliness of the event delivery. Or any guarantees that an event handler listening to it would be sure to execute entirely prior to the power mode change happening. This suggests to me that Keepass might not be locking the workspace as reliably as it seems.