Keepassxc: Provide unlocking via Pass+Keyfile OR Pass+Yubikey

[kalegrill]

Expected Behavior

Feature request to allow unlocking via (password | keyfile) || (password | yubikey).

Current Behavior

From what I understand, adding keyfile or yubikey to master key thus makes them mandatory.

Context

Some machines may be trusted more than the delivery channel for a db, perhaps a USB drive. Adding a keyfile or yubikey to the master password is great for security in that context. However, a keyfile still needs to be delivered out of band from the db then, and a yubikey would have to always be used after that.

An option, if this feature were implemented, could be to store the key from keyfile in the db, transfer the db via normal channel, unlock with yubikey and copy the keyfile. Then the yubikey is needed once for initial unlock but not again. Perhaps a machine is not trusted, then the keyfile doesn't need to be copied there and the yubikey can always be used.

[phoerious]

This isn't possible, because all key components are used for encrypting the database. You cannot decrypt it with a partial key.

[kalegrill]

What do you think of having one master key which can be encrypted with multiple combinations of components? I guess this changes the security architecture a lot and should be a separate issue, but it is an idea to allow this issue #892 to be feasible.

[jgbreezer]

one master key which can be encrypted with multiple combinations of components?

Every combination that can be used is one more attack vector; if any one mechanism is broken, your db is insecure. The more means to access the data you add, the less secure it is.

[kalegrill]

LUKS does something similar to this and is where I got the idea.

[TheZ3ro]

This is simply not possible, if you select Password + Yubikey, the entire database is encrypted with keymaterial from both of them. You can't decrypt the database by supplying only one of them, you will always need both.

[phoerious]

It is possible by creating several headers which contain the actual encryption key encrypted with different credentials. That would, however, require an extra file since we can't store multiple headers inside the KDBX file and I'm absolutely not a fan of sidecar files for a password vault.

[kalegrill]

Totally understand the sidecar sentiment. Thank you @phoerious for understanding the idea. I'm not sure how the headers work but I'm guessing changing them would break compatibility and be a hefty amount of work for questionable gain right?

[phoerious]

Yes.