Database locks much sooner than inactivity timeout

[brianjmurrell]

Overview

Database locks before inactivity lock setting

Steps to Reproduce

1. Set inactivity timeout in Tools->Settings->Security Timeouts panel to 43000 sec
2. Minimize KeePassXC
3. Wait [ much less than the 43000 sec ]
4. Notice database gets locked

Expected Behavior

Database should remain unlocked until 43000 sec have passed (and session is not locked)

Actual Behavior

Database locks only after a few minutes.

KeePassXC - 2.7.7 snapshot from #10189 @ b65d0a8
Revision: ???

Operating System: Linux
Desktop Env: Gnome
Windowing System: X11

[droidmonkey]

I cannot replicate this, do you have lock on minimize enabled? Have you unplugged a monitor which can trigger a lock signal sometimes? Also recommend resetting your settings by deleting the .ini file or using the "Reset Settings" button in the application settings.

[brianjmurrell]

I cannot replicate this,

I most certainly can. It happens here every day, multiple times per day so can you please reopen this ticket until the cause of the problem is discovered?

do you have lock on minimize enabled?

No.

Have you unplugged a monitor which can trigger a lock signal sometimes?

No.

Also recommend resetting your settings by deleting the .ini file or using the "Reset Settings" button in the application settings.

Why would this help? If it did help, clearly there is a bug somewhere. Here are my .ini file settings:

[General]
ConfigVersion=2

[Browser]
CustomProxyLocation=
Enabled=true
SearchInAllDatabases=true

[GUI]
MinimizeOnClose=true
MinimizeOnStartup=true
ShowTrayIcon=true
TrayIconAppearance=colorful

[KeeShare]
Active="<?xml version=\"1.0\"?><KeeShare><Active/></KeeShare>\n"
Own="<?xml version=\"1.0\"?><KeeShare><PrivateKey>[redacted]</PrivateKey><PublicKey><Signer>brian</Signer><Key>MII>
QuietSuccess=true

[PasswordGenerator]
AdditionalChars=
ExcludedChars=

[Security]
LockDatabaseIdle=true
LockDatabaseIdleSeconds=43000

Is there something in there that clearing them would resolve?

What steps would be necessary for me to take to help get to the bottom of this? Is there some debugging output that would be relevant? Would some debugging added to the code be useful? I can rebuild from source with whatever was needed.

[droidmonkey]

Please be more specific about exactly how much time elapses before a lock occurs. 30 seconds, 1.5 minutes, 2 hours?

[brianjmurrell]

I don't think there is any specific/predictable amount of time. It's also difficult to determine because there is nothing that positively alerts me when/that the database is locked. I only notice it's locked at some point that I go to use it.

Is there something I can monitor (i.e. dbus, debugging output, etc.) to raise a noticeable event (or log) when the database does get locked, to be able to more accurately answer this question?

[rafafaf29]

Hi, it's the same for me. I'm using version 2.7.4 (no NOT latest version) from Debian Bookworm repository, and it also has the described behavior.
When i don't use my computer, the database will auto-lock in something like 1 hour, although i set-up an inactivity time lock of 36000s (10h).
It seems to me that it won't lock while i'm using my computer, even if i don't use KeepassXC (directly or through browser extension).
But because i leave my computer quite often, i usually unlock the database several times a day (which is what i would like to avoid, as my threat model is very low and i'm most of the time alone in my flat).

If i can help in any way, please let me know.
Thanks !

[brianjmurrell]

@rafafaf29 For your use-case, you are probably more interested in #1404.

Like you, (and most people I suspect), I am vulnerable to multiple attack vectors.

First (and foremost in my opinion and situation) there's the security of my password database, which I am sure like lots of folks, I make available in an Internet Cloud Storage service as the KeePassXC maintainers recommend as the alternative to a central password storage service other implementations such as 1Password and the like use.

Then there is the vulnerability of the devices (PC, mobile devices, etc.) that I use to access that database.

In my estimation, the security of my database is paramount. In a cloud service, it is vulnerable to hackers as well as the employees of the cloud service. Therefore I want a very secure password on that database. But such a secure password is impractical to have to type in every time I have to unlock my computer. But that is fine, because, again in my estimation, my PC is less vulnerable than an easy to type password on my database and the password there is sufficient for the attack vectors it is subject to. Allowing my password there to parlay into the much more secure password on my database is a reasonable compromise in my case. But alas the KeePassXC maintainers do not agree and do not want to allow users to make that decision for themselves, by the comments on #1404.

[brianjmurrell]

This is most certainly (still) happening. I started a new instance this morning at 07:30:43 and am noticing now, at ~14:40 the database is locked. The screen has not locked since KeePassXC was started at 07:30:43.

[droidmonkey]

That is certainly much longer than "a few minutes" as originally reported. It's almost impossible to tell what your situation is, but I checked the code and our locking timeout couldn't be simpler.

[brianjmurrell]

That is certainly much longer than "a few minutes" as originally reported.

I subsequently expanded as my experience with the issue expanded "I don't think there is any specific/predictable amount of time."

I checked the code and our locking timeout couldn't be simpler.

Assuming it's a/the locking timeout. Maybe something else is erroneously triggering the locking?

Would it be useful to attach a debugger and put a breakpoint at the locking function and then check the stacktrace when it happens? What would be a useful breakpoint to add to do this would be useful?

[droidmonkey]

That would be super useful, yes

[brianjmurrell]

I have not really looked into the source for KeePassXC yet. What would be a good function to set a breakpoint on?

[droidmonkey]

https://github.com/keepassxreboot/keepassxc/blob/release%2F2.7.x/src%2Fgui%2FDatabaseWidget.cpp#L1711

This won't give much info in a stack trace if the lock is coming from a timer though, but that is also info that can be useful.

[brianjmurrell]

Figured this one out. This happens when the screen locking is blocked due to a mouse/keyboard grab by another application. This is done as a security measure to prevent the user from typing their password into an application that has grabbed the keyboard behind the locked screen, I believe.

In any case, the effect to the user is that their screen would have otherwise normally locked and then required unlocking, but instead, they get a brief notification saying the lock was blocked by another application and the screen doesn't actually lock. But KeePassXC actually processes that (failed) lock attempt as a successful lock and locks the database. But the user doesn't correlate that locking to the screen lock attempt that failed because they don't know the attempt failed while they were away from their computer and not there to see the brief notification popup.

You can simulate this failed locking by GNOME with the following commands:

gdbus call --session --dest org.gnome.SessionManager --object-path /org/gnome/SessionManager/Presence --method org.gnome.SessionManager.Presence.SetStatus 0; sleep 5; gdbus call --session --dest org.gnome.SessionManager --object-path /org/gnome/SessionManager/Presence --method org.gnome.SessionManager.Presence.SetStatus 3

During the 5s sleep above, open a context menu on some application. You will see that after the 5s sleep the screen attempts to lock but is blocked and a notification of such is displayed briefly. KeePassXC then locks the database.

I'm on the fence about what the correct procedure is in this kind of event.

[droidmonkey]

If we can't tell that the lock didn't actually happen, then we can't do anything. The signal shouldn't be sent out by gnome if no lock occurred. That's a bug on their side imo. I am closing this because the timeout is not the problem.....

[bitsondatadev]

Despite this not being an actual bug in KeePassXC, I want to applaud and thank @brianjmurrell for the detailed explanation on the issues you faced, and the troubleshooting steps you have outlined on this issue.

@droidmonkey thanks for your amazing work on KeepassXC! Would this make sense for me to contribute some note about this in the user guide or faq?

It wasn't too hard to find as it's like the first thing that popped up on Google but sometimes it's easier to just point out the nugget.

[droidmonkey]

Yes please do include a note section in the docs. That would be a welcome contribution