Keepassxc: 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.

[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.

[mightyCelu]

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.