search

keepassxreboot / keepassxc

KeePassXC is a cross-platform community-driven port of the Windows application “Keepass Password Safe”.
https://keepassxc.org/
Other
21.43k stars 1.48k forks source link

Add lock timeout based on overall system activity #310

Open vpelcak opened 7 years ago

vpelcak commented 7 years ago

At the moment there is an option to lock the database after some time of inactivity of the application.

Generally, I use other applications most of the time and need password from time to time (once in few hours). That is enough for the database to lock itself. This kind of defeats the feature of the automatic fill up of the login and passwords, since that requires the database to be open.

If the locking was determined by the (in)activity of the whole system, that would be better, yet, would not leave the database to be vulnerable when not in use.

Use case:

I use the database at work and at home.

At work, I need to use password every now and then. Therefore it is beneficial for me to have the database open for the whole time I use the computer at work. However I lock the screen whenever I leave my desk.

However after I leave home, I would also like to be able to open and edit the database at home. Therefore automatic locking of the database after system inactivity is the feature that covers this for me.

If this is too hard to implement, feel free to close, I'm happy enough to see that KeePassXC is being actively developed and I can workaround my need simply by having 2 databases - work and personal. But I would prefer to not to.

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

  1. Unlock the database
  2. Set timeout for locking the database
  3. Use other programs, but not the database.
  4. Database is locked after timeout

Context

Your Environment

droidmonkey commented 4 years ago

Yes we have a discussion label for issues that are not pending any implementation

Uj947nXmRqV2nRaWshKtHzTvckUUpD commented 2 years ago

are there any updates? we need this feature because it is way too annoying typing master password every time..

WhyNotHugo commented 2 years ago

I'd also very much appreciate this feature. The Lock databases when session is locked or lid is closed does not seem to work (at least not on Linux, see https://github.com/keepassxreboot/keepassxc/issues/8194).

I'm currently in a situation where I have to pick between typing the database password all the time, or leaving it permanently unlocked.

YannikBartel commented 1 year ago

yeah, i'm still wondering about this behaviour in 2023.

WhyNotHugo commented 1 year ago

Is it possible to use the browser-socket to lock the database?

It's trivial for me to write a tiny helper that awaits n minutes of idle and tells KPXC to lock itself. I really don't see a need for this to be implemented in-process.

michaelk83 commented 1 year ago

Is it possible to use the browser-socket to lock the database?

On Linux you can use DBus: https://github.com/keepassxreboot/keepassxc/wiki/Using-DBus-with-KeePassXC

WhyNotHugo commented 1 year ago

On Linux you can use DBus: https://github.com/keepassxreboot/keepassxc/wiki/Using-DBus-with-KeePassXC

This works, but I'd also need a signal that indicates when a database has been unlocked.

Currently, I can lock the DB after 10 minutes of idle, but then I don't know when to start the next timer, since I don't know when the DB has been unlocked.

droidmonkey commented 1 year ago

Does it matter? Just send a lock request when the timer expires due to inactivity. If the database is already locked its a no op. Your timer reset is based on system activity, not database lock status.

WhyNotHugo commented 1 year ago

Once I lock the database I have no moment at which I can start the next timer. Starting it immediately would just wake up the system to re-lock a locked database every ten minutes. It's not ideal, but to be honest it should work fine.

WhyNotHugo commented 1 year ago

The following works to auto-lock the DB after 10 minutes of idleness. It should work on any wlroots-based compositor.

#!/bin/sh

while true; do
  wayidle -t 600
  gdbus call --session --dest org.keepassxc.KeePassXC.MainWindow --object-path /keepassxc --method org.keepassxc.KeePassXC.MainWindow.lockAllDatabases
  # TODO: wait for signal indicating that the db is unlocked again.
done
nykoo commented 6 months ago

This lacking future of lock timeout based on overall system activity could be a main reason for me to return to keepass original... :( Really hop this will be implemented.

Migsi commented 6 months ago

Once I lock the database I have no moment at which I can start the next timer. Starting it immediately would just wake up the system to re-lock a locked database every ten minutes. It's not ideal, but to be honest it should work fine.

The following works to auto-lock the DB after 10 minutes of idleness. It should work on any wlroots-based compositor.

#!/bin/sh

while true; do
  wayidle -t 600
  gdbus call --session --dest org.keepassxc.KeePassXC.MainWindow --object-path /keepassxc --method org.keepassxc.KeePassXC.MainWindow.lockAllDatabases
  # TODO: wait for signal indicating that the db is unlocked again.
done

Why don't you just start the script when the screensaver was unlocked/the user logged in? Based on the presented use cases in this thread I'd think this system idle timeout will always be hit some time after the screen locked, which would make a screen unlock the perfect time to restart it. In case your Keepass was never unlocked, it would be a no-op just as @droidmonkey stated. Still it wouldn't wake your system every x minutes to do basically nothing.

I still think having this tied to Keepass itself would be the cleaner and more universal approach. Alternatively, if FIDO2 support gets merged in, some sort of quick unlock (ideally tied to the system/screensaver unlock) could mitigate this whole issue completely. Thinking of it, that should even be more secure than an independent timeout could ever be. Such a thing should probably be discussed in a separate issue though.

WhyNotHugo commented 6 months ago

Why don't you just start the script when the screensaver was unlocked/the user logged in?

There is no correlation between screenlocker and KPXC being locked; KPXC will be auto-locked even if the screenlocker is inhibited. The KPXC timeout is not necessarily longer than the screenlocker timeout either (this particular value varies depending on host and other conditions).

I still think having this tied to Keepass itself would be the cleaner and more universal approach.

Most Wayland compositors use a dedicated protocol, ext_idle_notifier_v1. I haven't found any indication of Qt actually exposing the interface in any way. I'm not sure how feasible it is to implement this without explicit Qt support.

Mutter specifically doesn't support ext_idle_notifier_v1 and uses its a bespoke D-Bus interface. This might be easier to implement, but will only work on a single compositor.

Generally, I think that providing the right hooks for external processes to handle this allows better per-desktop integration.