KeeChallenge for YubiKey, and why you should avoid it

KeeChallenge is a plugin that adds YubiKey support to KeePass 2. YubiKey adds another layer of protection to your database: in order to decrypt the file, the owner has to present their physical YubiKey.

How KeeChallenge works

KeeChallenge encrypts the database with the secret HMAC key (S). This key is stored in the YubiKey and is used for generating responses. Additionally, KeeChallenge encrypts the S with the pre-calculated challenge-response pair, and stored the encrypted secret and challenge in an auxiliary XML file.

When you unlock the database:

  1. KeeChallenge loads the challenge C from the XML file and sends it to the YubiKey
  2. The YubiKey transforms the challenge (using the secret S stored in the key) and returns a response R
  3. The response R is used for decrypting the secret Senc stored in the XML file.
  4. The decrypted secret S is used for decrypting the database. Importantly, this is the same secret as the one stored in YubiKey.
  5. KeeChallenge regenerates the XML file (generates a new random challenge C, calculates the new response R, encrypts S using R’, and stores the updated C and Senc to the XML file)

For more detail, please check the full workflow diagram.

Problems with KeeChallenge

There are several security issues with KeeChallenge’s approach:

  • The secret key never changes, it only gets reencrypted. From KeePass’ point of view, KeeChallenge is no different than a static key file that provides the same bytes every time.
  • As a result of the above, KeeChallenge is wide open to replay attack. Any of the previous XML files can be used to decrypt the database. That is, there is no point in randomizing the challenge and re-encrypting the secret — it is a security theater.
  • The secret should never leave the YubiKey — this is the whole point of a write-only hardware key. KeeChallenge violates this principle by bringing the secret to computer. Theoretically, an attacker can copy S from process memory, clone owner’s YubiKey without owner’s knowledge and decrypt any future version of the database (since the secret is static).

Moreover, there are a few related problems:

  • A developer from Yubico raised a security concern in 2016. As of 2022, the issue is still open.
  • KeeChallenge looks abandoned, there were no meaningful updates since 2016.
  • The maintainer does not respond to issues.

A better alternative

An alternative approach was introduced in KeePassXC and is supported by all compatible apps:

In KeePassXC, we do not require any knowledge of the HMAC secret. We use the database’s master seed (a random byte string that is part of your database) as challenge and then use the response to encrypt the database. That way we do not need an extra file and also gain the advantage that the required response changes every time you save the database, which resembles actual two-factor authentication more closely.

This approach has multiple advantages over KeeChallenge:

  • The key derived from the YubiKey is dynamic, it changes on every database save. (In KeeChallenge, the encryption key remains the same, effectively simulating a static key file.)
  • The HMAC secret never leaves the the hardware key, so the YubiKey cannot be covertly cloned.
  • There is no auxiliary XML file, only the database itself.
  • There are several active developer teams that support this approach.

For the reasons described above, KeePassium implements the KeePassXC’ approach. There are no plans to support databases encrypted with KeeChallenge.

If you have a KeeChallenge-protected database — consider switching to KeePassXC and KeePassium instead. This combination will provide you with more secure, compatible and maintained solution.

See also

Last Updated: 2022-03-14