keepass2android icon indicating copy to clipboard operation
keepass2android copied to clipboard

Feature idea: Fingerprint + Quick unlock

Open PhilLab opened this issue 5 years ago • 6 comments

The unlocking via fingerprint is a very convenient feature. However, a fingerprint can easily be taken without consent (there were reports of toddlers unlocking their parent's iPhone by placing their thumbs on the phone while sleeping. And not to mention more violent situations)

QuickUnlock by the last three characters also is very convenient but I am reluctant to use it because I am unsure if reducing my password effectively down to three characters is too risky for me.

What about combining both? I.e. You need the Fingerprint AND the QuickUnlock characters (or an additional pin #170 , but I think this would take longer to implement).

PhilLab avatar Dec 15 '19 10:12 PhilLab

I like this idea...

As an aside, @PhilLab - you can increase the length of the quick unlock key.

Settings -> App -> QuickUnlock -> Length of QuickUnlock key

If three chars is too short, try increasing it. One failed attempt w/quick unlock hard locks the database. So with a slightly longer key, the chances of a child or some other malicious actor unlocking the db with QuickUnlock can be very slim.

schlomie avatar Dec 17 '19 18:12 schlomie

@PhilippC this might be mergeable / related with #399

PhilLab avatar Jun 30 '20 09:06 PhilLab

I found an additional, more concise argument why this feature request rocks: QuickUnlock does not survive the phone reboot. Full biometric unlock does survive it.

Two possibilities, how this feature could be implemented: a) User is asked for biometrics. With them, the database key is retrieved from the keystore. The user inserts the last three characters which are compared with the key. If they do not match, the biometrics (and characters) have to be given again to slow down brute-force.

b) User is asked for the biometrics and the last three characters. With the biometrics, a key is retrieved from the keystore which is the database key but encrypted with the last three characters the user has entered (this obviously weak key is stretched to slightly increase the encryption quality). The key is decrypted and the database unlocked. If they do not match, the biometrics (and characters) have to be given again to slow down brute-force.

I don't know about the thread model of the Keystore so I am not sure if b) makes any sense at all, but at least it would slightly reduce the trust you have to put into the Keystore as a user.

PhilLab avatar Dec 31 '20 12:12 PhilLab

~This seems to already be available in the latest version of the app. (Look for it in the Biometric unlock section of the database's settings, not in the Quick Unlock section of the app's settings)~

BHSPitMonkey avatar Nov 20 '21 08:11 BHSPitMonkey

I don't think this is true. @PhilLab was expecting to have both Biometric+Short code, currently you can only enable one of those

PhilippC avatar Nov 20 '21 08:11 PhilippC

This is an excellent idea; when combined with a relatively short easy to type custom QuickUnlock (key in DB root) it's more convenient than always entering master password with no possibility of physical observation revealing it and provides good protection from unauthorised fingerprint use attacks.

To maintain convenience, it'd be great to have settings for: biometric only QuickUnlock active timeout, biometric only QuickUnlock sleep timeout. This way, we can have short lock DB timeouts, convenient QuickUnlock while actively using the phone and when it sleeps for a short time while we do an urgent task.

To further minimise master password entry on reboot/app killed/deliberately closed, we could have a "regular access" password and biometric protected Keystore secret to derive the encryption key. This prevents physical observation being helpful in accessing the DB on a different device that doesn't have a secure element + biometric unlock.

elahn avatar Apr 20 '25 03:04 elahn