On Quick Unlock, try additional hardware keys if specified key is unavailable

[Jonas-Bruell]

Have you searched for an existing feature request?

• Yes, I tried searching

Brief Summary

After a full login into the password DB, it is possible to have the DB "quick locked" with Touch ID (goes to the screen with the fingerprint icon, no password required) and then "quick unlocked" via Touch ID. This is a feature I really like.

I use a hardwarekey as an extra layer of protection to my passwords, so every time I want to "quick unlock" my DB, I need to make sure my hardwarekey is inserted into my pc (so far so good, this is as it should be)

The feature I would like to see added, is that you can "quick unlock" your DB with a different hardwarekey to the one you did the "full unlock" with. Both hardwarekeys should ofcourse be registered in the DB first.

Although this is a very small feature, I would be a nice quality of life upgrade.

Example

I have 2 hardwarekeys registered in my DB: Key_A and Key_B

I have just restared my pc and want to unlock my DB with my password and Key_A.
After a while, the DB "quick locks" itself due to inactivity
Now I want to unlock my DB with Touch ID and Key_B.

At the moment, Keepass complains that I have the wrong hardwarekey (Key_B) to unlock the DB via Touch ID, although Key_B is registered into my DB. I have to go back to the "full login" screen and unlock the DB with my password and Key_B, to unlock it. --> quick unlocks only work with Key_B now, not Key_A

Context

I have a shared DB on a shared computer that I use with a coworker. My coworker has a hardwarekey and I have a hardwarekey. We both have the password to the computer and the password to the DB.
When I log in to the DB with the password and my hardwarekey (full login), after the DB locks automatically, my coworker has to cancel the "quick unlock" and enter the password with his hardwarekey.
Same the other way around, if my coworker logged in first, I have to cancel the quick login and do a full login.

[droidmonkey]

Torn on this one. We store the Serial Number and Slot Number in the quick unlock data to know exactly what to query when performing an unlock. If we fail to find it, we could try "other connected keys" until it works, however that is an unbounded problem (let's say you have 10 keys as an extreme example).

[Jonas-Bruell]

Wouldn't you be able to bound this loop by the amount of hardware keys that are saved in the database? Say you do have 10 keys saved in the database, then you only have to query a maximum of 10 times? After 10 tries, the key is not in the DB?

Or maybe it is possible to store all the Serial- & Slot Numbers in the quick unlock data? (10 keys saved in the database -> 10 keys stored in the quick onlock data?)

Then again, I don't have a clue what I am talking about as I am not familiair with the techstack, or maybe doing it this way could be a security vulnerabilitiy?

It is a small frustriation I have with otherwise amazing software that I have been using and trusting for almost 10 years now, keep up the good work! 🤗

[droidmonkey]

We dont save any key information to the database.