Keepass locks up CPU when handling very large passwords
A lightweight and easy-to-use password manager
Brought to you by:
dreichl
Menu
▾
▴
#2195 Keepass locks up CPU when handling very large passwords
I was using Keepass to store gamesaves for multiple accounts on a game, which are stored as text. These files are 7000-15,000+ characters. When storing this text in the password field of an entry, the password quality is displayed as blank and the password length is displayed as 0 characters, and the thread calculating the password quality locks up. For a password of length 5000, it takes about 30 seconds to calculate the password quality and then CPU usage returns to normal (and the password quality and length are displayed when the calculation completes). For a password of length 14,700, I left it running and it took 12 minutes to finish calculating (so it is indeed not locking it up indefinitely, but it is still increasing exponentially with password length).
Every time you open the "edit entry" screen, it starts a new thread to calculate the password quality. When the "edit entry" screen is exited, this thread continues to run even though it has nowhere to display the calculation if/when it completes. So if you are quickly editing 10 very large entries, your CPU will jump to 10%, 20%, 30%.... and very quickly hit 100%, which will make Keepass (and the rest of your computer) run very slow until you either wait 12+ minutes for each thread to complete, or close Keepass. If someone else had a use-case like mine but their files were larger, they would very quickly reach a point where Keepass would be locking up their CPU for days (which may as well be indefinitely).
Possible solutions:
1) (Best solution) Check the length of a password before doing a password quality check, and skip the password quality check for passwords above a certain length (and perhaps add an advanced option to disable this behaviour, in case someone is running the program on an alien supercomputer and actually wants to let their CPU calculate for passwords in the thousands)
2) (Okay-ish solution) Leave the behaviour intact, but kill the thread making the calculation when the "edit entry" screen is exited (since it has nowhere to display the calculation anyway), preventing multiple threads from locking up the entire CPU (and preventing a single thread from running forever when you are no longer editing an entry).
3) (Bad solution) Decide this is not a use-case you want to allow in Keepass, and limit the size of the password text field (also note this could break people's databases if they update and already have large passwords in their database)
My solution (until this is fixed) is to simply use the "notes" field for my specific use-case. However, using the password field did have benefits (hotkeys, etc). It is very cool that by finding and reporting bugs in a game I am playing by messing with multiple accounts, I also found a bug in Keepass lol.
Forgot to post my specs:
Windows 10
Keepass 2.52 (64-bit)
XSL Stylesheets - Installed
Keepass LibC (1.x File Support) 1.40.1 - 0x01C2
Bug also existed in older versions, since I updated when I discovered it (in case it had been fixed already, and it had not)
Save the data as text in an attachment on the Advanced tab instead.
Create a new blank file and use the built-in editor.
cheers, Paul
Yes, I can also save it in the "notes" field. But that's a workaround. Keepass in its current form can still lock up machines due to the bug. That's not good and should be fixed.
I'm only familiar with Github and Java, but if it's just a simple length check with a conditional statement wrapped around it (my first solution), I could probably figure out C#, C++, and Sourceforge, and fix it myself. I work full-time retail though, so it'd probably take me a while. I haven't written code in forever. (And figuring out how to get the project to build properly from source might be quite a stumbling block for me)
Calling it a bug is a stretch - who would have imagined a 15k password. And why set an arbitrary limit?
Maybe test password length before the quality check and ask to check if it's very long?
cheers, Paul
I posted 3 solutions. Did you read the second one? kill the thread making the calculation when the "edit entry" screen is exited (since it has nowhere to display the calculation anyway),
It's a multithreaded program, and a thread is generated to calculate the complexity of a password. And keeps running even when the screen that will receive the output is closed. There is no reason for that thread to continue running when the screen is closed. And there is no reason for multiple such instances of such threads to be running concurrently, ever (which is what happens when you open multiple entries). I wouldn't say calling this a bug is a stretch.
I am, however, not very familiar with multi-threaded programming, so that solution (killing the thread when the screen is exited) would probably not be possible for me to figure out in a language I am unfamiliar with.
It doesn't need to be arbitrary. You could put an option in the advanced settings and allow users to choose a length.
I don't think an annoying popup every time is a very good solution when you could put an advanced option in the settings, set it once, and be done with it.
You could always use a custom field and hide it in memory. Then you don't get the quality test.
No discernable lag in my testing.
cheers, Paul
Last edit: Paul 2022-10-15
If you insist on keeping this information in the password field, you should know that KeePass allows quality estimation to be disabled individually for any entry. On the Edit Entry screen, click the button with the blue "(i)" icon to the right of the quality bar to turn it on or off for that entry.
This solves my issue, thanks. I guess I won't have to go through a several month-long journey to patch it out myself. (But I still might, just for fun. Who knows.)
I have adapted to not keeping this information in the password field, but I was still concerned about this bug because if I fat fingered the wrong field by accident, it would lock up my CPU for several minutes. With the quality check disabled for these entries, that is no longer an issue.
Yesterday i was creating a password and leave my position. Some weight falled onto the keyboard and started digiting a password.
Today my pc's fan was noisy, CPU 100% and Keepass completely freezed. I stopped any key pressure and Keepass still not responding after minutes
I repeated the test manually and i find that - after key pressure removal - keepass is still struggling to:
1: filling in the password (keyboard input is faster than graphical password prompting and the deelay increase with pressing time)
2: calculating password lenght
3: calculating complexity
I was opening a new ticket, but found this.
This behavior persist in 2.55 win10 and win11.
I upvote the 1) solution for backward compatibility and stability
Anyway password length is not password complexity and so should not be so impacted especially for a "serial" rate like keyboard (meaning not ctrl-v stuff)
As has been said, don't put really long strings in the password field, or turn off quality calculation.
cheers, Paul