Decrypt password on access by Yubikey

[fruh]

Summary

Current situation of yubikey usage is following:

• master key is generated by yubikey HMAC-SHA1 Challenge Response
• yubikey takes user password and seed to generate master key
• after entering user password and tapping yubikey, whole database is decrypted in memory and master is destroyed (I guess)

It would be great security feature, if password and attachments are nor decrypted to memory on database unlock, but only on read/write access (copy, edit).

Desired Behavior

It should work in following steps:

• database is encrypted by master key generated by yubikey HMAC-SHA1 Challenge Response m_key = y_hmac(salt, user_password)
  • password and attachments are encrypted with different encryption key - entry_key = y_hmac(entry_salt, user password)
  • there is used per password/attachment salt
• on database unlock, passwords and attachments remains encrypted
• only read/edit access password/attachment will be decrypted by yubikey HMAC-SHA1 Challenge Response - entry_key = y_hmac(entry_salt, user password)

Context

It makes stronger security to password database:

• in case of compromised computer no passwords/attachments are leaked, or only currently used can be leaked. Because they are encrypted with different encryption key than whole database and they are not decrypted in memory (only currently used one).
• yubikey requires user interaction (finger tap) so they can not be decrypted by malicious process automatically

[phoerious]

Thank you for your suggestion, but this is almost certainly a wontfix.

Your description of how YubiKey decryption works isn't quite correct. A YubiKey only generates an extra key component which is then used by KeePassXC together with a password and/or a keyfile to calculate the final master key, which is then run through the key derivation function.

Usage of a YubiKey as you suggest is incompatible with kdbx. It could perhaps be implemented, but no other program except KeePassXC would be able to read passwords and attachments. The challenge-response mode of the YubiKey also isn't really meant to be used with key presses, but as a passive dongle that does not require further user interaction. Though, if you do require user interaction, it makes exporting a database or merging entries virtually impossible (but even without, it would be extremely slow and error-prone). It also prevents searching within the database, but I think by far the worst issue is that you would permanently lose access to all passwords and attachments if you want to remove or change the YubiKey associated with the database, unless you re-encrypt all of them, which is pretty much impossible. We would need to decrypt them first and and then re-encrypt with the new key, which is entirely infeasible, particularly with user interaction for each decryption and encryption operation. You would also need to write a decrypted version first or have both keys plugged in at the same time.

[tinyapps]

Hi @fruh, You're probably already familiar with it, but for anyone else stumbling onto this thread, ZX2C4's pass offers exactly this sort of protection: all passwords remain encrypted other than the one requested. However, this comes at the expense of exposing some metadata (though there is apparently an extension to hide it).