Advanced unlocking doesn't replace hardware key authentication

[kaoneko]

KeePassDX 3.5.0. Happy to see YubiKey support! I bought the Pro version as a thank you ❤️🙏🏻

While Advanced unlocking says in its settings menu that it Lets you scan your biometric to open the database or Lets you use your device credential to open the database, it doesn't replace authentication with a hardware token (challenge-response), whereas I expected it to work the same no matter what type of credential the database is protected with. Let me explain...

Use case 1, working: I have a database protected with a password as the sole credential. I can provide the password and then tap the fingerprint icon to setup Advanced unlocking. From then on I can unlock the database with my fingerprint.

Use case 2, not working: I have a database protected with a hardware key as the sole credential. I activate Hardware key and select Yubikey challenge-response from the drop down menu. I then tap the fingerprint icon and it says Type in the password, and then click this button (whereas the Password credential wasn't even enabled).

What I expected to happen: I tap the fingerprint icon, it asks to scan my fingerprint and then my hardware key, and from then on lets me unlock the database with my fingerprint and only asks for the hardware key after I make a change to the database. (Just as it would be inconvenient for me to type my password every time I use KeePassDX to fill in some credentials, it's inconvenient to retrieve my keyring and hold it to my phone everytime I use KeePassDX to fill in some credentials.)

I always thought Advanced unlocking just stored the decryption key of the database in the device's TPM, but maybe I misunderstood and it just stores the password. In that case, when my only credential is a hardware key with challenge-response, it should store the response (and do so everytime it changes as well). (And when I also use a password, it should store the combination of password + response I guess, while also providing the option to replace only one of the factors with Advanced unlocking.)

Additionally let me address the fact that people tend to consider a hardware token a second factor for additional security, while it can be perfectly fine to use it as the sole factor. Replacing a password with a hardware key has its own advantages. Please consider this perspective if your gut reaction is something along the lines of "you shouldn't even want to do what you describe here". Thank you.

[J-Jamet]

KeePassDX 3.5.0. Happy to see YubiKey support! I bought the Pro version as a thank you heart🙏🏻

Thank you, it is much appreciated. :tada:

Currently, the advanced unlock connection with the Keystore is only made on the password, so you can always use the other factors separately.

I do not recommend keeping the physical key as the only factor, the best is to cumulate 3 factors: Something you know - the password Something you have - the key file or hardware key Something you are - here unfortunately the fingerprint is not part of the hash as it is not standardized, so I thought I could make the key file compatible with advanced unlocking. https://github.com/Kunzisoft/KeePassDX/issues/1420 https://github.com/Kunzisoft/KeePassDX/issues/1315

The hardware key does not need to be compatible with advanced unlocking, as its purpose is to be present when there is a file opening or modification, otherwise there is no point in having a hardware key.

[kaoneko]

The point is to not have to remember or store a password anywhere. It surprises me how hard it is for people to think outside of the box and see the applications of a hardware key as the sole factor. We use it in so many other areas of our life: homes, cars, lockers. But in ICT, the password is this untouchable foundation of security and everything else is complementary. You're urged to use a hardware key as a second factor, but talk about using it as the FIRST factor and people just can't wrap their minds around it as if the concept is too far out there. At the same time, when you mention using only a password is sufficient for your threat model, people will just urge you to make it a strong randomly generated one. Which is of course what only using a hardware key also accomplishes (the response of a YubiKey is 40 random characters), with the additional benefit of it being much harder to intercept the password.

Using a YubiKey with challenge-response instead of a password gives me:

• a very long randomly generated password
• that I don't need to remember, store and type
• that automatically changes regularly
• that is much, much harder to intercept than a regular password
• thus for all but the most skillful attackers, the requirement of being in possession of a physical token to access the database

So the only thing a password would add is protection against real world attacks (i.e. theft of the YubiKey), which are not a part of my threat model. So I trade in the theoretical gain in security for an actual gain in convenience. Everyone's threat model is different of course, but reading discussions on the internet it seems to me that a lot of people are so caught up in theorizing about maximum security that they don't pause to consider someone's threat model.

Forgive me the rant, it's not meant as an attack or anything, just needed to vent that I guess.

Regarding the issue at hand, I realized it's actually not a big inconvenience to scan my YubiKey every once in a while—I don't even need to access my keepass vault that often anyway (on my phone). I just assumed Advanced unlocking would work with any credential, the UI is not clear on the fact that it only works for passwords (hence I chose Bug instead of Feature). And just like with most apps, where you usually only provide the login credentials once and then it remembers them for you and sometimes additionally protects access to the app with your fingerprint or a PIN, I thought I'd provide the credentials to my database only once when setting up my phone and would then be able to access it with my fingerprint. Those were my expectations...

O well, I hope this wall of text provides some insight into the kind of usecase where using just a hardware token to secure a database makes sense and expecting it to work with Advanced unlocking is not as crazy as it may sound ;)

Cheers!

[J-Jamet]

I did not say that only the password was sufficient. I only said it was best to have several factors. You can see the hardware key as the first factor and the others as other factors, it doesn't bother me at all. If you notice, the UI shows switch buttons to select the factors independently of each other, without the need to have a password, so that the user can use the unlocking mode he wants. ;)

I understand that the interface needs to be revised for the advanced unlock association, historically KeePassDX is a fork of KeePassDroid and the fingerprint unlock was only linked to the password. As I said, I would like to improve the concept to make it compatible with the key file as well.

It's not crazy, never says that either, for me it is just not useful to make it compatible with the challenge response because the main purpose of this unlocking is to have an external physical access of the user. When you use your car key, you often register it on another device to unlock your car with your fingerprint?

[kaoneko]

No, but on smartphones it's quite normal to only need full authentication once when setting up an app, and after that being able to access it after unlocking your phone or the app with your fingerprint or PIN, because the device is now "trusted". So I thought of Advanced unlocking in that frame of reference.

[J-Jamet]

With Keepass2Android, once you've unlocked your DB with your Yubikey, you can unlock, read, and autofill from it with only your fingerprint. You do still need the key to edit an entry though (which is fine).

I think you are talking about KeePass2Android's quick unlock (because I don't understand the purpose of unlocking an already unlocked database), but the quick unlock simply leaves the database open in memory, but not visible to the user. This is not a solution : https://github.com/Kunzisoft/KeePassDX/wiki/Advanced-Unlocking#why-not-quick-unlock

The use of the Yubikey is precisely to add a layer of security that REQUIRES an action from the user. If this is not the behavior you are looking for, simply do not use this factor. But it's like every time, you have to make a choice between usability and security.