Add lock timeout based on overall system activity

[vpelcak]

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

• KeePassXC version/commit used: (can be found under Help -> About)
• Qt version (e.g. Qt 5.3): Qt 5.7.1
• Compiler (e.g. Clang++3.6.0): gcc 6.3.1+r245113
• Operating System and version: openSUSE Tumbleweed

[phoerious]

Duplicate of #134

[TheZ3ro]

There is a PR pending #135

OT: This time @phoerious was faster

[vpelcak]

Sorry, but this is not duplicate at all.

I wanted to have the option to choose timeout to be started by the inactivity of the whole system in instead of the inactivity of the KeePassXC itself only.

In other words: That specified timeout starts when I stop being active on the desktop. If I set the timeout for 1 hour, lock the screen and then return and unlock the screen after 10 minutes, I still would like to have the database to be open.

[phoerious]

Okay, that sounds like a slightly different use case. Such a timeout must not interfere with the "normal" inactivity timeout, though, because it would basically mean that the DB never locks as long as you are using your PC.

I don't know how difficult this would be to implement on the different platforms.

[TheZ3ro]

This seems pretty useless to me because you can instead set a timeout autolock in your OS screensaver and lock KeePassXC with #135

[vpelcak]

Well, I'm locking the screen whenever I leave the computer. Once the screen is locked, I don't care if the database is as long as it is closed some reasonable time after I stopped using it to allow it being opened in other location. Yet I would like to have the database not locked while I use the machine and have the computer under control.This thing is completely irrelevant to screen being locked or not. What I care about is,  that the database doesn't lock the file while I use the computer and may potentially need it.Dne 15. 2. 2017 9:14 odpoledne napsal uživatel TheZ3ro notifications@github.com:This seems pretty useless to me because you can instead set a timeout autolock in your OS screensaver and lock KeePassXC with #135

—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.

[TheZ3ro]

So you simply have to disable the KeePassXC timeout and use the screensaver locking

[vpelcak]

I also use the database on more machines. Therefore I also do need automatic locking. I updated the bug description to explain my use case.

[TheZ3ro]

I don't know how hard it is to implement a "global" timeout for system inactivity that also is cross-platform

But still I don't understand why you can't set a screensaver for system inactivity. At Work you lock your PC and KeePassXC will lock. At Home the screensaver will do the same job as a "global" timeout

Correct me if I'm wrong

[vpelcak]

I leave my desk and lock the computer rather often. Therefore locking the database when locking the screen is out of the question for me. I will not enable this option at all (but I understand that some people may need it and will use it). It simply does what I don't need. I want the database to not to lock ideally for the whole time I'm using the computer.

The same for screensaver. I don't need it and don't use it. It brings no benefit for me.

At work I either sit at the computer or leave it for a short while. When I leave it for longer time, then I'm going home. Therefore 30 minutes system inactivity timeout would correctly guess I left home, and when I am at home, I can open the same database synced over Dropbox and modify it because it locked in meanwhile on my machine at work.

[phoerious]

You can always use a database, even when it's locked, as long as you don't write two it from two different locations at the same time. But I would argue that leaving the DB unlocked and then go home is not the most secure way to handle your password database.

[vpelcak]

Well, I know. But I intend to write to it if needed.

Why is it insecure? If the screen is locked and nobody knows my password?

[phoerious]

Because it's unencrypted in memory. Someone with physical access to the machine can circumvent the lock screen and get their hands on your passwords.

[TheZ3ro]

So at work you leave your PC unlocked with no screensaver/autolock but KeePassXC should lock by inactivity of the whole system?

(At home you lock manually when you leave the desk, ok)

[vpelcak]

phoerious - well, I'm well aware of this, however it is unlikely to happen. TheZ3ro - no, I lock at work, at home I don't lock at all.

[mihaiile]

While I see the user use case I think it is not one that many would use. I am not saying it should not be implemented, but care should be taken not to turn the settings part about the auto locking too confusing, it adds unnecessary complexity to the application, too many settings/options, etc. I would add this as something like a advanced configuration one would manually add in a configuration file or something.

[vpelcak]

Have you ever used Enpass? It has this ability without looking confusing. Sorry, but only you make it overly complicated.

[phoerious]

It's not trivial to implement cross-platform. Only because others have done it, it doesn't mean it's easy to implement. And I agree that different settings for different timeouts are confusing. If this gets implemented, we need to be very careful about the settings and how we present them. We don't want users to configure timeouts which don't work as they think they do.

[vpelcak]

Naturally. You are the developer, your call.

Thank you for your work. Regardless you implement my request or not.

[anatoli26]

This setting was implemented from the beginning in the original KP and the global timeout setting was already requested in #100, with a corresponding printscreen of its implementation in the original KeePass. IMO, those who migrate from KP, won't have any issue with the new setting, moreover, they expect it.

My rationale for this setting is that one may have a short screen lock timeout (say 5 min), so the screen locks quite frequently during the day (say, while at the desk on a phone call, going to WC, etc.), but one would like to lock the KP only after some extended timeout, say 15 min (going to lunch), i.e. leaving the PC for enough time to perform any physical manipulation with it.

Now, this is indeed something not that simple to implement on all platforms. Maybe we could start with Linux, as Windows already has its solution?

[anatoli26]

If you are interested in a Linux solution, there's an utility xprintidle which prints the time in ms since the last user activity (keyboard/mouse), quite robust, works well on unlocked and locked session. If you inspect its source code (http://archive.ubuntu.com/ubuntu/pool/universe/x/xprintidle/xprintidle_0.2.orig.tar.gz it's just 136 lines .c file) there are basically 3 functions: XOpenDisplay > XScreenSaverQueryExtension > XScreenSaverQueryInfo. Then there's also a workaround for a bug in XScreenSaverExtension when dpms is running, quite trivial too.

So, IMO this option could be introduced conditionally for now (i.e. available on Linux, grayed-out on other platforms), then maybe someone could provide a solution for Windows and OS X.

[fonic]

This answer nicely sums up possible solutions for Linux, Mac OS X and Windows: https://stackoverflow.com/a/21905027

I'd be willing to contribute the Linux part.

[sergeevabc]

Frankly, I'm completely puzzled why this function has not yet been implemented.

Common scenario: user switches on the computer, some apps are launched, one of them is a password manager, it sits in the tray waiting to be unlocked by auto-type shortcut (e.g. when user wants to get into webmail), then it stays unlocked (since other password-based resources are likely to be accessed) and becomes locked only after X mins (e.g. 15) of user’s idleness (distraction, nature’s call, sleep, clash, etc).

[UkeFan]

My Mac Version closes after few minutes of inactiviy no matter what I put at timeouts ):

[Barleyman]

This seems pretty comatose. Re: discussion, it's in original Keepass and not confusing at all. I can see many users wanting to keep the database open while they're using the computer, I certainly do. It's irritating having to type in the DB password over and over. My screen lock timeout is not very long because I don't always remember to lock the PC when I go to the loo etc.

I guess increasing the screen lock timeout and tying database lock to that would make this behavior less annoying, at least the database won't lock when I'm busy working. But KP behavior of having an explicit "only lock if AFK for xx time" is the best option.

[phoerious]

Not sure what you mean. We have options for both locking after some time of inactivity and on lid close/suspend.

[Barleyman]

Inactivity of keepasxc, not of the system, which is the whole point of this bug. It'll happily lock every half an hour (or whatever idle is set to) on the background while I'm busy working on something.

[sergeevabc]

Inactivity of keepasxc, not of the system, which is the whole point of this bug…

Dear sir, this issue is named, I quote, “lock the database after some time when system is inactive, not KeepassXC”, whereas you ask for “lock the database after some time when KeepassXC is inactive, not system”. So your request requires another issue to be created and this one seems to be resolved to date.

[Barleyman]

Inactivity of keepasxc, not of the system, which is the whole point of this bug…

Dear sir, this issue is named, I quote, “lock the database after some time when system is inactive, not KeepassXC”, whereas you ask for “lock the database after some time when KeepassXC is inactive, not system”. So your request requires another issue to be created and this one seems to be resolved to date.

No I didn't. That behavior is how it works now.

[droidmonkey]

The wording of the issue title is rather confusing

[sergeevabc]

Hmm, the issue is far from being resolved. For example, I set “Lock databases after inactivity of 30 secs”, then minimize KeepassXC and scroll a webpage with the latest news, so there is an activity, obviously. Yet in 30 secs I see KeepassXC has locked its databases. WTF?!

[ovz93br43v7]

My KeepassXC database locks itself automatically while surfing although I have disabled the option autolock at an inactivity of x seconds.

[GeorchW]

@phoerious Would you accept a PR on this? I can't test it on all platforms, since I don't own a Mac. But I could probably provide an implementation for Windows and X11.

From the "confusing for users" side of things, my proposal would be to replace the setting

[x] Lock databases after inactivity of [X sec]

with two settings

[x] Lock databases when not using KeePassXC for [X sec]
[x] Lock databases when not using system for    [X sec]

I would be quite surprised if users were puzzled by this, but if that's still confusing, explanatory tooltips could be added.

[phoerious]

I don't like adding another option that perhaps 0.01% of our users will actually have a need for. There has to be another solution for this.

[tsumare]

@phoerious, I understand that's hyperbole, but do you really think so few people will think "I want to have my passwords available while I'm working, but secure them when I leave my computer"?

This is a distinct concept that doesn't overlap with the existing idle setting. Either you make it an option, or you force it on everyone who prefers the other method. Must we really be so stingy?

"I want my passwords available when I'm here, and secure when I'm not" can hardly be rare. Does no one work in one application for a while, then later log into another? Especially with the browser extensions, this is a common workflow. Make them mutually exclusive if you want, but this option is certainly needed.

[phoerious]

I think hardly anybody will care about the distinction between activity in KeePassXC and activity in the system. The timeout as it is now means it will lock if you haven't actively used KeePassXC within the last X seconds (we may actually add browser extension requests to this @varjolintu). If you want it to stay open indefinitely while you are working, disable the timeout. It will still lock once you lock your screen. We already have four different settings that control how and when KeePassXC shuts the door. I do not fancy adding yet another.

[sergeevabc]

+1 for “lock after SYSTEM inactivity”, been waiting for this to happen for God knows how many months.

[droidmonkey]

@sergeevabc, do you regularly leave your computer unlocked when not in use? You have not described your specific NEED for this feature based on some sort of requirement in your daily use case. The problem with having two timeouts is that the system timeout effectively nullifies the keepassxc-only timeout. This makes for redundant settings. It also confuses the purpose of lock on screen lock, which is a best practice for security.

[GeorchW]

Hmm, if adding a single option for this use case is already too much then I can hardly think of anything that meets your standards. Considering that this issue is one of the more upvoted ones, I don't think that the use case is too rare.

Anyway, the thing is that I have a long database password, but a short computer password. When I'm just grabbing a cup of tea at work, I don't want to have to insert my long database password again. So I just lock the computer, then come back a few minutes later, unlock the computer and continue working. If I get caught up in a longer conversation on the way, no problem, my database is automatically locked.

The second problem is that I'm sometimes called, don't do any input for a few minutes since I'm concentrated on other things, and then my screensaver pops up. Now, this is no problem, the screensaver does not require password entry if interrupted in the first few seconds (i.e. moving the mouse), and even if, the password is short. But if I use the "lock on screensaver" option, then the database instantly locks, and I have to type the long password again.

As long as I don't have this option, I won't set any "user inactivity" or "close on lid" setting, because it is too tedious to type the password all the time, even if I was just gone shortly or was on the phone. So at least in my use case, this setting would improve security.

(On the other hand, I don't really see a use case for "lock after KeePassXC inactivity", so if it was up to me, that setting could be replaced, but it's probably there for a reason.)

[robsonsobral]

This is something I miss from KeePass. I bet a lot of people doesn't use it just because they never thought about it. To lock the database after I leave my desk would be awesome.

And I also agree to @GeorchW . "lock after KeePass inactivity" isn't that useful, except if you share a computer. But, in that case, to leave your database unlocked is another kind of problem.

[phoerious]

I disagree. KeePassXC inactivity is quite useful if set to a sensible timeout (15-30 minutes). If you don't need a password within this time, the database will lock itself.

[droidmonkey]

Thank you for the use case demonstration @GeorchW, that does make sense to me.

[anatoli26]

I too was waiting for this option for years. My use-case is opposite to the described one: I have a long delay till the screen locks, but I'd like the KP DB to lock itself after some timeout shorter than the system session timeout, but unrelated to the KP usage timeout (the existing option).

[Barleyman]

I would imagine for most users current inactivity setting would be the "wrong" or unexpected behavior. What's the use case for locking the database if you're actively working on the computer?

Granted, screen saver can mitigate that but as pointed out, maybe you don't want the database to lock while going to hey coffee..

On Tue, 14 Apr 2020 at 02:43, Anatoli notifications@github.com wrote:

I too was waiting for this option for years. My use-case is opposite to the described one: I have a long delay till the screen locks, but I'd like the KP DB to lock itself after some timeout shorter than the system session timeout, but unrelated to the KP usage timeout (the existing option).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/keepassxreboot/keepassxc/issues/310#issuecomment-613180208, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFJJEGXVIRAHL6C2VQ2GS3RMO5TJANCNFSM4DAHRMZA .

[outdooracorn]

My use case is similar to @GeorchW and I agree with @Barleyman, what's the point of locking the DB on a computer you are actively using?

My vote is for replacing KeePassXC inactivity with system activity. I think this will be more useful to the majority of users.

[sergeevabc]

We ask, we explain, we persuade… damn, for 3 years already… that locking is about locking the app if user is not present near computer like it is done in the original Keepass, and yet recent 2.6.0b1 is released with the same misleading, detached-from-reality “lock if app is not used” timer on board.

[droidmonkey]

@sergeevabc It's crazy to me that in 3 years time you couldn't teach yourself C++ and write your own implementation, maybe even go so far as to submit it as a pull request so that everyone else can enjoy your amazing work. I've been too busy with the 800 other Pull Requests that have been reviewed, written, merged, and released so that you can enjoy 2.6.0b1.

[GeorchW]

@droidmonkey I think that @sergeevabc refers to the fact that most of the time, this feature was not accepted at all. For most of the three years, the maintainers of this project were arguing that they would not accept a PR in this direction (e.g. here). While I absolutely honor your work and see how you're offended, I think that he does make a valid point.

It's generally unattractive to maintain an own fork of any software: on each update, you have to manually pull and rebuild. This can be automated, but is still very tedious and prone to breaking. For security-critical software such as a password manager it might be dangerous to not get any updates for a prolonged period of time.

(Also, knowing that you just gave something back to the community is a motivation in itself, while the process of getting your PR denied might be frustrating.)

I think a clear statement that a PR is welcome for this feature would help a lot. I don't have the time right now, but I'm sure that, since this is one of the more popular issues (no. 20/500 or so based on upvotes), someone eventually will.

[droidmonkey]

No PR for this has been submitted. An issue that is open and marked as new feature is by definition waiting to be implemented by anyone. Most of the conversation in this thread is discussing whether the already existing lock on screen saver / screen lock sufficed. Additionally how this timeout compares to the kpxc specific one.

For the record I am not offended, this is not the only issue that @sergeevabc has been laying rude comments on.

[GeorchW]

An issue that is open and marked as new feature is by definition waiting to be implemented by anyone.

Huh, okay, didn't realize that. I thought that the issue was open because discussion was encouraged, not because implementation was encouraged. Thanks for clearing that up.

For the record, I did not intend to defend @sergeevabc's tone, which I do consider unacceptable. :-)