Support multiple master key configurations per database

[frankmorgner]

Summary

When creating (or unlocking) a DB, keepassxc allows specifying what's known as composite key in keypass2, e.g. a master password with a key file. All those credentials seem to be required when unlocking the DB.

Desired Behavior

Ideally, I'd like to use the the key file if it is available. If it is not available, I'd like to use the master password. So the question is whether it is possible to unlock the DB with a single credentials from many possible credentials. Would that be possible or is this already implemented?

Possible Solution

In essence, we're not creating a composite key anymore, instead we're creating a key from each credential which independently unlock the DB.

Context

Think of the way Pluggable Authentication Modules (PAM) can be stacked, combined or used separately, for example.

[droidmonkey]

This is not how encryption works.

[frankmorgner]

OMG, I hope you're not treating all your users like this. Let's just say we had a bad start and I'll explain with a different example:

When using disk encryption with multiple user accounts you have a single password protected key for each user. This user key is then used to decrypt the disk encryption key from a user specific cipher text so that every user can decrypt the same disk without knowing anything from the other users. This is not a problem of encryption, just a matter of key management. Would it be possible to add such key management to the Keepass DB?

[droidmonkey]

Ok that makes more sense, you store multiple encrypted versions of the master key with the various credentials. Here is my personal issue with this from a database perspective. If you are able to decrypt with JUST the password, your key file is totally irrelevant and does not provide any additional protection. So just don't use it.

Sorry for the blunt response.

[michaelblyons]

I agree that the example provided is bad, but once (more) hardware tokens are working, having two approved hardware tokens makes sense to me, least one be lost.

[frankmorgner]

Just be more creative: What about password+Challenge/Response that can be used as alternative to smart card+PIN? Both variants have a similar security level allowing me to use whatever I am carrying with me...

[frankmorgner]

According to the documentation, KDBX 4 at least has some room to store custum data for plugins. That could be a fit for alternative decryption credentials...

[droidmonkey]

Where this does lower security (especially if you allow password-only in lieu of Challenge-Response/Key File) it also allows for multiple users of the same database with different passwords (also "dead man switch"). There is some value in supporting this feature, but it would be KeePassXC only supported (not portable) and carries risk that must be communicated to the user. This also complicates the master key setup.

[frankmorgner]

What's the status of interoperability? Which KDBX features are supported across different implementations?

[droidmonkey]

We are fully interoperable with KeePass 2.x, all active clones, and several KeePass plugins. The only KeePass KDBX feature we don't support yet is tags. Supporting multiple credentials would certainly be an outlier in that model.

[droidmonkey]

After storyboarding this for a little bit I came up with a couple gotchas:

1. Anytime the original master key changes (manually or when using Yubikey) then all additional keys would need to be entered to encrypt the new derived master key.
2. When entering credentials, we would have to assume it was the original master key first, fail decryption, then test any additional keys. Given a KDF that takes 1 second to derive, this could lead to multiple seconds of delay (even more so on lesser powered devices).
3. As discussed above, you can inadvertently lower your security threshold with additional credentials that are less robust.

This discussion is very similar to the "give the FBI a master key" concept. Having multiple pathways to an encrypted resource ultimately reduces the security of that resource.

[mxsrc]

I like this proposal a lot, I think there are use-cases where this would not lower security, but rather improve it.

Consider a user who secures the database using only a strong password, rather than a weaker password with a keyfile, such that the database is self-contained and can be unlocked just with the password. If he'd like to automatically unlock the database when logging into/unlocking the computer, he might be tempted to use a simpler, less secure password, since it has to be typed regularly. With the proposed feature, it might be possible to have two variants of accessing the database: with a strong password, or with a weaker password and a keyfile that is present only on the computer with the associated login.

[speakman]

This is exactly what I'm looking for. Or just that simple case of using multiple Yubikeys - current FAQ even recommend you to use two Yubikeys using the same key!!

In my case I would like to either have a very strong password (or rather a passphrase, see xkcd 936) OR a Yubikey. Where the passphrase is the backup if the yubikey gets lost.

LUKS is using "slots" where different methods can be combined. Any active key will unlock the master key which in turn is used to encrypt the disk.

For a bigger company, handing out multiple Yubikeys is a common practice. Whenever a keys is lost, it's keys/certs are revoked immediately but there are no disturbance in the work for the employee. A new backup key is sent out. Just thinking of having SAME KEY in these keys is truly a nightmare!

[frankmorgner]

yeah, this advice is rather stupid.

I've originally posted this here, because I thought keypassxc was a bit more permissive ragarding new ideas. Anyway, I switched back to KeyPass for using https://github.com/mlaily/KeePass-CertificateShortcutProvider. This creates a smartcard (yubikey) encrypted blob on your disk containing your password. Basically, your password is still the only key to your database, but now you can decide whether you want to type the password or if you want to use your token to recover the password instead.

[frankmorgner]

This approach should work with any number of tokens...

[d-faure]

IMHO, if the primary reason to a tool such as KeepassXC is the user's inability to remember it's passwords, why do believe that he can have better chances at this with the master one? Therefore an alternate authentication feature should be available for the master password to let him have a chance if he needs to.

An interesting implementation could for example take advantage of Shamir's secret sharing algorithm in order to securely take account of a subset of user conditions to validate the database opening (the regular master password, the key file or even the yubikey token being some of them).

[d-faure]

My example algorithm wasn't the right one to use.
Cf. this answer to encryption/decryption with multiple keys, thre's perhaps better way to handle this.

[cornfeedhobo]

It's really a shame that this never went anywhere. LUKS was right to have slots and time has proven that this does not weaken the net security model of the user, especially given that the average user won't use this feature and thus the attack surface remains the same.

If someone decides to tackle this, I'd be willing to pay a bounty.

[iameru]

I would also enjoy this feature a lot.
This could also be used in having a somewhat friendly password rotating system. currently, changing the master key just means I will be locked out if I cant remember the new one which i just got and dont have memorized yet. Having multiple slots I could have the old one as a fallback for some days until turning it off.

[Hoeze]

I just got a new Yubikey and wanted to set this up:

• long passphrase as backup
• short passphrase + yubikey for everyday use

I was catched by surprised that KeePassXC does not support this and would love to use this feature 👍

[Hoeze]

Adding another use case:
In our lab, we have a KeePassXC database for all important passwords shared between us admins.
My plan was to add each admin's yubikey as one unlock token instead of sharing a single password between us.
This is only possible with key management.

[michaelk83]

If you're sharing the database with all the important passwords, then using a separate password for each admin doesn't really add much security, as I understand. If any one of them is compromised, all the passwords can be accessed.

But, you can set this up using helper databases and AutoOpen. The main DB uses the long secure passphrase, and each helper DB is set up to use one of the YubiKeys, and to AutoOpen the main DB.

[Hoeze]

Oh cool, I did not know that you can use AutoOpen to open other databases!
Thanks for the tip :)

---

Yes, it is not really more secure if the DB gets exported when unlocked.
However, hardware tokens cannot be cloned and add some convenience if I just need to press a button on my yubikey + type some short PW.
Also, since we rotate the DB at least yearly, I do not need to remember changing passphrases.

[droidmonkey]

@Hoeze this example is a good time to note that KeePassXC is not an enterprise credential management solution. KeePass in general is fundamentally a personal/individual credential manager. You can do limited team access, but don't abuse the flexibility 😅