Biometrics: any reason to store the raw password rather than the transformed final password?

[aamerabbas]

Hi Jeremy,

I was just debugging the app out of curiosity and wanted to see how biometric unlocking works. If I understand correctly, the app relies on the Android Key Manager and does a simple base64 encoding before storing the raw password (https://github.com/Kunzisoft/KeePassDX/blob/master/app/src/main/java/com/kunzisoft/keepass/biometric/AdvancedUnlockManager.kt#L258).

Is this accurate? If so, why not store the final transformed key instead of the raw password? This would make the unlock much faster since it would not have to go through all the transform rounds to unlock the database. I was actually thinking about doing this as a weekend project and submitting a pull request.

However, I thought about this and I see a security issue. The issue is what would happen if you are using a key file. In this case, even if the keyfile is deleted, the biometrics would allow the user to unlock the database. This seems like a security flaw, of course.

I wanted to check with you to see what your thoughts are on this. Is the keyfile scenario the reason why you choose to store the raw password rather than the final transformed password?

[aamerabbas]

Sorry, quick correction. I just re-read the code and I think I was wrong about the base64 part. Seems it uses a cipher and not just simple base64 decoding.

But still, it seems what is decrypted is the raw password and not the final key. So my question is still the same.

[J-Jamet]

Hi Aamer,

The main password is obviously encrypted in the Keystore of the device with a cipher and a key that can be temporary depending on the options you have chosen. https://github.com/Kunzisoft/KeePassDX/wiki/Advanced-Unlocking#e-optional-temporary-encrypted-key-memory
The Base64 only allows to store the encrypted data more easily to avoid bugs.

There are several reasons to get only the raw password:

• As you say it allows to manage the key file separately. This is a great advantage when you have a key file on a separate device (USB), it allows to differentiate the keys of the user. The main purpose is to make unlocking easier, so you don't have to retype a long password and it makes it not possible to decipher the database without the separate key file.
• This will make it easier to define a new standard. Some users ask for the fingerprint to be a full-fledged key in addition to the password. Since compatibility with other applications is needed, this would be a fingerprint key (converted to string for compatibility) defined as part of the main password.
• The code already was initially in KeePassDroid (as KeePassDX is a fork) and did not confuse users.

If you make a pull request for this feature, it would be good leave the current operation too. So a setting would be a good idea but I'm afraid that users would be confused (perhaps only an explanation on the wiki is needed)

The unlock time is an important concept but as phones are now as powerful as computers (and I'm trying to improve the KDF algorithms), the unlock time is the same as on PC so for me is not really a problem.

[aamerabbas]

Thank you for the detailed explanation Jeremy. I think those are convincing data points. I am convinced it probably doesn't make sense to add this change, so I will hold off on the pull request. Appreciate your quick and helpful responses, as always.

[nomis]

The database could be modified by another application or on another device to reconfigure the password hashing (without changing the password). It wouldn't be possible to open the newer version of the database unless the raw password had been stored.

Users may want to reconfigure password hashing based on the performance of all devices that need to unlock the database without having to re-enter the password everywhere.