Add QuickUnlock Feature

[seatedscribe]

With the newest and coolest feature of passphrase generator finally merged in, I find this request even more opportune - as you could tell, I have a LONG passphrase as master key for any of my databases, so my opinion may be a little biased 😄

A rationale for this feature request is best explained by the author of keepass2android. I use this app regularly on a daily base and could not even think of practically handling the unlock procedure without this service. Here it goes, step by step (courtesy of https://keepass2android.codeplex.com/)

You should protect your password database with a strong (i.e. random and LONG) password including upper and lower case as well as numbers and special characters. Typing such a password on a mobile phone every time you unlock your database is time-consuming and error-prone.

• Use a strong password for your database
• Load your database and type the strong password once. Enable QuickUnlock
• The application is locked after the time specified in the settings
• If you want to re-open your database, you can type just a few characters (by default, the last 3 characters of your password) to unlock quickly and easily!
• If the wrong QuickUnlock key is entered, the database is locked and the full password is required to re-open

Is this safe? First: it allows you to use a really strong password, this increases safety in case someone gets your database file. Second: If you loose your phone someone seize your laptop and tries to open your password database, the attacker has exactly one chance to make use of QuickUnlock. When using 3 characters and assuming 70 characters in the set of possible characters, the attacker has a 0.0003% chance of opening the file. If this sounds still too much for you, choose 4 or more characters in the settings.

I am not an expert on how this should be done correctly from a crypto perspective, but I am available and open to collaborations so to have this feature implemented ✅

[StefanB08]

I agree that it is practical and use it myself, but it do actually makes your DB a lot less safe against a advanced attacker. The safety example is only true if you do not take cloning/imaging into account. By cloning the unit, the attacker will have a indefinite tries to enter the correct password. And as you have practically shortened your 70 character keylength down to a very weak 3 character password it will be possible to unlock the unit in a very little amount of time.

By using the quick unlock there is also a chance that the user will lock themselves out of the DB if they forget the true password and is only used to enter the short version of the full password.

I'm not against quick unlock, but I strongly believe it's critical to not mislead the user into thinking they are more or even equally secure by using it.

[TheZ3ro]

I think this is a good thing for an opt-in option with the ability to select the length.

Like @StefanB08 suggested, if your adversary have great capabilities this will effectively lower your security. For the average user I don't think it's a great problem so opt-in is fine by me.

Also an important side note, this option will need the master password stored in memory (for decrypting the database when the QuickUnlock is entered)

[sudoforge]

I'd be much more a fan of enabling QuickUnlock with some other identifier, such as a separately-set PIN. This PIN can be a configurable length (it should probably default to 4), and can only be used to unlock the database during the current KPXC process if the database has been unlocked before -- to ensure the PIN (the "QuickUnlock passphrase") cannot be used to unlock the database from a new process / session.

This enables the ease of use of quick-unlocking a database without requiring the passphrase (or a subsection of the passphrase) to be repeatedly entered.

Windows 10 implements such a feature, where the user is only required to enter a small string of characters (a PIN in this particular case) that is - critically - not the same as their user password. This prevents keyloggers* or drive-by onlookers from being able to utilize the information they gather.

* This is assuming that the keylogger doesn't have access to the keyboard when it is entered initially.

[seatedscribe]

@StefanB08 I agree with you that in this scenario (a laptop in the hands of the cruel enemy) quick unlock is the least feature one wants enabled for his password manager. But at the same time we can think of alternatives, like having also a yubikey inserted which can reduce the risk of a brute force attack. As before, this should be an opt-in depending on the paranoid level of the user 😄

@bddenhartog having a PIN unrelated to the master password reduces the attack surface. Should the PIN remain the same from session to session, or is it to be generated anew every time KXC is launched?

• In the latter case it could be challenging (or a good memory exercise) since it changes frequently;
• In the former case, where is it supposed to be stored in the DB? @TheZ3ro maybe KDBX4 can be extended to allow this feature? Just sayin'...

[sudoforge]

quote @seatedscribe:

@bddenhartog having a PIN unrelated to the master password reduces the attack surface. Should the PIN remain the same from session to session, or is it to be generated anew every time KXC is launched?

• In the latter case it could be challenging (or a good memory exercise) since it changes frequently;
• In the former case, where is it supposed to be stored in the DB? @TheZ3ro maybe KDBX4 can be extended to allow this feature? Just sayin'...

It would definitely be most convenient to store the (non-ephemeral) PIN in the database settings; and I agree that this would be the preferred method of storage (over say, storing it on disk [permanent] or in memory [ephemeral]).

As a workaround to the current impossibility of storing the PIN in the database settings, perhaps we could read the PIN from the CLI (not unlike --pw-stdin does), and/or look for the value in a .keepassxc configuration file in the user's home directory?

[TheZ3ro]

Implementation wise, all those options are not available to us.

We have 2 cases:

1. Using a PIN not related to the master password (stored somewhere, doesn't matter now)
2. Using some character from the master password

In both those cases, if the master password is not stored in memory, you won't be able to unlock the database. By having a PIN or some char of the master password you can't derive the complete master password. (The DB is directly encrypted with the masterpassword)
And also if your database is locked with a Yubikey, you can't unlock it in both cases above if you don't have the Yubikey inserted.

[droidmonkey]

@TheZ3ro i believe you use the pin or last chars to encrypt the composite key in memory. Am i correct?

[TheZ3ro]

@droidmonkey should be a viable option, but then you shouldn't store the PIN anywhere and decrypt on demand

[droidmonkey]

The pin is known by the end user thus not stored.

[TheZ3ro]

@droidmonkey yes, I was clarifying this:

As a workaround to the current impossibility of storing the PIN in the database settings, perhaps we could read the PIN from the CLI (not unlike --pw-stdin does), and/or look for the value in a .keepassxc configuration file in the user's home directory?

[TheZ3ro]

Closed accidentally, my bad. Reopened

[ArchangeGabriel]

With regard to PIN QuickUnlock, I was wondering if we could somehow have TOTP QuickUnlock? That would be interesting for me. Getting a TOTP token from my phone would still be way faster than typing my full passphrase. I know since @TheZ3ro answer to my comment here that TOTP is not suitable for initial unlocking, but maybe it could be here?

[Keisial]

@ArchangeGabriel, QuickUnlock protects the master secret with the "easier" one (precisely so you don't have to type your full passphrase). You can't do that with TOTP for the reasons explained in that comment.

You may want to open a new request to have an option of not actually locking keepassxc but leaving everything in memory awaiting a TOTP token.

[Keisial]

@TheZ3ro What's the problem with storing the PIN in the database itself? It's probably less sensitive than other db contents. It could be stored with no view interface, so that brief access to an unlocked instance doesn't allow later compromises.

[TheZ3ro]

@Keisial we don't have such a filter, all entry in the DB are displayed. We can store it like KeePassHTTP Settings but then you will need the masterpassword to access it/read it.

A viable solution can be:
Store a new entry called KeePassXC QuickUnlock PIN as the masterpassword encrypted with the user-selected PIN (I will call this QuickSecret). This will be stored in the DB encrypted with the masterpassword itself.
Then once the DB is unlocked for the first time the QuickSecret is loaded in memory. Whenever the DB is locked again KeePassXC will ask for the PIN, decrypt the QuickSecret to get the masterpassword and the unlock the DB. If the PIN is wrong, delete from memory the QuickSecret so an attacker has only 1 attempt.

The only problem in this setup is that what we call "masterpassword" can be: 1 password, 1 keyfile and/or 1 yubikey.

Sincerely, I don't really like adding another way to unlock my databases so I think we should get this right if users want this feature.
I will look into KeePass2Android code to see their implementation.

[dok18]

Any news about this?

[droidmonkey]

This is a wishlist item, no plans as of right now to implement.

[TheZ3ro]

I was looking into this and noticed that KeePass2Android does the QuickUnlock by asking X character from the master-password

The master-password is stored in memory in plain-text [1], the masterkey (master-password + keyfile + yubikey) is also stored in memory so it can unlock the Db just fine [2]

This implementation will not work with KeePassXC since once the user inserted his master-password, the plain-text is thrown away and only an hash of it is kept in memory.
So we can't really ask for the first 10 digit of the master-password since KeePassXC doesn't have this information and can't check if it's correct. Only the full master-password hash will match.

I will think about it

---

[1] https://github.com/PhilippC/keepass2android/blob/17cbb754a6d46cc3dfae3399804d796014b3cddf/src/KeePassLib2Android/Keys/KcpPassword.cs#L77
[2] https://github.com/PhilippC/keepass2android/blob/4a738990ae9807bb30629df9551650e99ee82640/src/keepass2android/QuickUnlock.cs#L323

[seatedscribe]

once the user inserted his master-password, the plain-text is thrown away and only an hash of it is kept in memory.

What about storing the hash of the last n characters along with the hash of the full master-password? This way the quick password can be processed the same way as the full-size password...
Basically I'm saying the db is protected with a master password which is a subset (last n chars) of the original, but only one attempt is permitted. Is it still too weak of an approach?
(please be kind, I'm no expert here) :)

[electrofloat]

There's another implementation where you can choose between a part of your master password or an entry in the database itself:
https://github.com/JanisEst/KeePassQuickUnlock

[electrofloat]

@TheZ3ro

The master-password is stored in memory in plain-text [1], the masterkey (master-password + keyfile + yubikey) is also stored in memory so it can unlock the Db just fine [2]

I don't know how did you come to a conclusion of it is stored in plain-text.
The linked linked line shows:
m_psPassword = new ProtectedString(true, pbPasswordUtf8);
and if you go a bit further:
https://github.com/PhilippC/keepass2android/blob/17cbb754a6d46cc3dfae3399804d796014b3cddf/src/KeePassLib2Android/Security/ProtectedString.cs#L175
https://github.com/PhilippC/keepass2android/blob/17cbb754a6d46cc3dfae3399804d796014b3cddf/src/KeePassLib2Android/Security/ProtectedBinary.cs#L288

So ProtectedString with utf8 byte array seems pretty much encrypted to me.

[phoerious]

The string itself may be encrypted, but the decryption key for it has to be stored in plain text. Otherwise you wouldn't be able to access the data.

[Corey-Keller]

I mean you do you, but you do realize that the actual key that encrypts your database is only 32 bytes long? It is a transformed SHA-256 hash of your "key data". So if you want to be really technical about this, the maximum search space to unlock your database, no matter how long your password is or key file or yubikey, is 32 bytes. That is a huge amount of possibilities, by all accounts infinite, but your 100 character password and internal 2000 character password are not providing any additional protection beyond that search space.

I actually didn't know that. Neat! Thanks for the info. Correct me if I'm wrong, but that means that there's no security benefit to a master password (again, using that as a catchall for whatever combo of pw, keyfile etc. that make it up) with >256 bits of entropy correct?

But part of the desire for quick unlock is that we're dealing with 2 different attack surfaces:

1. a 'fully locked' database. This is the db as is when you first open KeePassXC (if using QuickUnlock for subsequent unlocks, if you're not then it applies to every unlock); here your attack surface is anyone who can get access to your database at all by any means, so high security is crucial. This is like hosting a server that is globally internet accessible; as long as you have the right credentials it doesn't matter where you are, you can get in.
2. A database that has been unlocked at least once on the machine, but is now locked. Here the attack surface is MUCH smaller (only those with access to the machine where it has been unlocked), so a somewhat less secure unlock method isn't as risky. This is like restricting access to a server to those in a specific place (server only accessible when on site or possibly connected to a secure VPN) or device. Instead of just anyone who has the credentials wherever they are being able to access the server, only those that have sufficiently proven themselves (on site, and thus approved by security, and/or connected from a company approved device) can access it.

[michaelk83]

Correct me if I'm wrong, but that means that there's no security benefit to a master password with >256 bits of entropy correct?

This may be a bit outdated, but you can use this chart (or any number of similar ones) as a guide. Just as a couple examples, 15 lowercase letters should take 1000 years to crack, according to this chart, and 18 lowercase letters would take 23 million years to crack. That assumes the password is completely random.

15 lowercase letters is 1.7 * 10^21 combinations, which is equivalent to 70.5 bits of entropy. 18 lowercase letters is 3 * 10^25 combinations, or about 85 bits of entropy. So you get diminishing returns above 70 bits or so, and anything above 90 or so doesn't make much of a difference.

---

Anyway, I think this comment summarizes the situation well. They're working on it (or at least are aware of the demand), but it's not an easy feature to add. The tricky part is handling the master password securely after the initial unlock.

If you can contribute a PR, you can ask the devs where to start. Otherwise, adding your own "I want this" comment isn't going to make this go any faster.

[michaelk83]

Update: It looks like fingerprint support will make this feature easier. MacOS TouchID already functions as a sort of QuickUnlock. #6029 is trying to implement the same on Windows, and I suppose the Linux side will need to do something similar.

Once those is in place, regular QuickUnlock is pretty much the same thing, just without the biometrics. But there's a bit of a TODO list to finish them.

[MoneyAllDay]

With keepassxc-browser, would it be possible to also:

1. On browser, in a website with login input fields, click on the Keepass icon;
2. Manually input password to open database at first once;
3. Next time when filling user/pass fields just click on the icon and the extension would auto unlock the database and do its thing;
4. If the browser is closed the database password is "wiped from the cache". Requiring a start from step 1.

Of course the database password would be encrypted somehow in keepassxc-browser.

Having to type the password manually each time can get tedious, specially for those people who are on PC with timeouts enabled and 99% of the time opening the database is only related to the browser.

Any chance, this or a similar method is implemented in v2.7.0?

[aamerabbas]

3. Next time when filling user/pass fields just click on the icon and the extension would auto unlock the database and do its thing;

I will let the team comment on this, but I don't think this is possible. The extension just connects to the running instance of the app gets the credentials from there. This is part of the security as it ensures the extension itself doesn't actually hold any data. If the app is locked, the extension could not unlock it.

[6677028]

I look forward to this feature. I hope the 2.7 update we will have. This is a very nice feature that Keepass and Bitwarden already have.

[christophschw]

As a workaround, I configured fprintd / pam for my root account and store the master key of the KDBX in root's GNOME Keyring. IMO, this is a good compromise between UX and security.

Editing my desktop file to this Exec line does the trick for initial unlocking via fingerprint:
bash -c 'pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY secret-tool lookup application Keepass | keepassxc --pw-stdin ~/Nextcloud/Dokumente/Passwoerter.kdbx'

Unfortunately, #2089 is blocking the UX after DB lock. Unlocking via this method fails with:
Another instance of KeePassXC is already running.

[phoerious]

Closing this, since KeePassXC has been supporting quick unlock on Windows and macOS since version 2.7.0 and we don't need this to track Linux support.

[paddylandau]

Closing this, since KeePassXC has been supporting quick unlock on Windows and macOS since version 2.7.0 and we don't need this to track Linux support.

Where is LInux support tracked, please? Linux is already on version 2.7.1.

[michaelk83]

Where is LInux support tracked, please?

#5991

[R4ygen]

Closing this, since KeePassXC has been supporting quick unlock on Windows and macOS since version 2.7.0 and we don't need this to track Linux support.

Is a Pin unlock feature been implemented or does this refers just to the fingerprint / face unlock methods?
In the latter case, does there is another ticket open for a Pin unlock feature request?

[fnadde42]

Honestly, what is worse? That I use a PIN code that is not super safe since it requires storing master password in RAM..... OR... That I leave my DB completely open anyway, with it stored in RAM, since it's such a hassle to type in the master password all the time.

[michaelk83]

The current QuickUnlock uses Windows Hello on Windows, which AFAIK can be configured to use a PIN instead of a fingerprint. Don't know if that would actually work that way, but theoretically it should. (Can someone test this please?)

If the Linux implementation will be done via PolKit, it should be possible to configure it the same way, depending on your flavor of Linux and DE. In both cases, the preferred type of authentication is up to the host OS.

On macOS, QuickUnlock uses TouchID, which by the name of it is probably limited to biometrics (don't know). If so, then PIN unlock on macOS would require some additional code.

[R4ygen]

Honestly, what is worse? That I use a PIN code that is not super safe since it requires storing master key in RAM..... OR... That I leave my DB completely open anyway, with the master password stored in RAM, since it's such a hassle to type in the master password all the time.

Afaik, the most used plugins on the OG KeePass work in a way that encrypts the hash of the master password with the PIN you provided. So yeah, it reduces the security of the database to a weaker password, but only locally and on an already booted system. And you only got 1 try with the pin or it relocks the db, but dunno if it helps in a direct memory attack.

Security notes for the KeepassQuickUnlock plugin, and the LockAssist plugin.

The current QuickUnlock uses Windows Hello on Windows, which AFAIK can be configured to use a PIN instead of a fingerprint. Don't know if that would actually work that way, but theoretically it should. (Can someone test this please?)

Can confirm you can use a PIN for Windows Hello if you prefer it yes. My only worry is that it would be the same pin you use to unlock the pc, which is usually pretty weak and known to multiple users of that pc, and easily recoverable via "I've forgot my pin / password". It would be nice to have a separate pin only for unlocking Keepass, and maybe, isolated from the system, by being a part of Keepass itself instead of relying on OS dependent functions and security. (that would also be a big help for cross compatibility between systems, even for just the pin option)

[paddylandau]

… the same pin you use to unlock the pc [is] known to multiple users of that pc

That in itself is a security issue beyond KeePassXC. Each user should have their own account with their own PIN, and KeePassXC cannot help if you share your PIN with others.

[amcsi]

… the same pin you use to unlock the pc [is] known to multiple users of that pc

That in itself is a security issue beyond KeePassXC. Each user should have their own account with their own PIN, and KeePassXC cannot help if you share your PIN with others.

Irrelevant. An alternative PIN or short password should be an option as an additional layer of security.