At the moment, I am using KeePassXC with a relatively strong master password. To further improve security, I thought about buying a YubiKey to have 2-Factor-Authentication.

KeePassXC supports the so called "HMAC-SHA1 Challenge Response mode".

In the KeePassXC FAQ they say:

Does KeePassXC support two-factor authentication (2FA) with YubiKeys?

Yes and no. KeePassXC supports YubiKeys for securing a database, but strictly speaking, it's not two-factor authentication. KeePassXC generates a challenge and uses the YubiKey's response to this challenge to enhance the encryption key of your database. So in a sense, it makes your password stronger, but technically it doesn't qualify as a separate second factor, since the expected response doesn't change every time you try to decrypt your database. It does, however, change every time you save your database.

Assuming an attacker has access to my KeePassXC database and perhaps even installed a keylogger on my system, the additional YubiKey is useless in this case, am I right here?

So, is it reasonable to use a hardware security key for KeePassXC if you already use a strong master password?


Well designed password managers do not rely on authentication for their security; instead they rely on encryption. So unlocking a password manager data base doesn't even involve single factor authentication, much less multi-factor authentication.

How a password manager can use a Yubikey

What this means is that the kind of thing that is normally used to strengthen an authentication process (and YubiKeys are very good at that) play an inherently different role when it comes to something that's security is largely based on local or end-to-end encryption. There are roughly three approaches, but the details of each matter.

1. Security theater

In some cases, the apparent second factor is pure security theater. It is possible to do something that looks like 2FA to the user but is trivially evadable by any attacker worth worrying about. We (at 1Password, where I work) have resisted intense customer pressure for that over years.

Let's just ignore this option. It does nobody any good and it has a substantial harm potential if users end up using weaker master passwords or not protecting their master password as well as they otherwise might. That is, if people weaken what is already the weak point in their password manager security, because they feel protected by theatrical 2FA, they very much weaken their effective security.

2. On some authentication component

Although many password managers can be used off-line, without requiring authentication to some remote service, there is typically a required authentication component when setting up a new device to get (at least) data synchronization to work. 2FA can be added to that authentication component, even though it is a minor part of the user's security.

This, by the way, is what we do with 1Password. If you enable 2FA, then it is required when setting up a new device. The hope is that by limiting it to this, we are not leading users to believe that they can get away with weaker master passwords or that the 2FA magically protects them from an attacker who gets at their locally encrypted data.

3. As a supplier of a static key

Decrypting data requires a key, and deriving that key requires user held secrets (typically their master password and perhaps other things). The difficulty here is the the key derivation function (KDF) must be deterministic (as it must derive the same key each time).

But the beauty of something like a Yubikey is that it can prove knowledge of a secret without revealing it. They are designed to work in a challenge-response manner, where each challenge is randomized, making the responses unique each time; yet each correct response proves knowledge of a secret. This is what makes these things really good in authentication contexts. But this is useless during key derivation.

So having the Yubikey spit out a static secret is operating the device in a mode that gives up on its most important security features. It's doable (as Keepass is apparently using it and some of our users have jerry rigged something similar), but it really isn't offering the security guarantees that a Yubikey normally does.

Although this isn't purely security theater (there is some real gain), there is still distinct possibility that users will over value the security gain and thus weaken the parts of their security (master password) that should be stronger.

Is it reasonable?

So back to the original question. It is reasonable to use a Yubikey as described in (3)? Using it is not unreasonable as long as you understand what it does and doesn't protect you against (and that these are distinct from what a Yubikey typically protects you against.)

We, at 1Password, however, believe that it is unwise for a password manager to encourage (3), as the security benefits don't seem to be worth the security threats that arise from people's misunderstanding of the security properties. However, I very much understand the customer pressure for this kind of thing. I also understand that reasonable people may come to different conclusions.

| improve this answer | |
  • 1
    Funny answer. "Oh yeah the U2F provides security, so use Yubikey with 1password, but its challenge response mode doesn't provide that much security, so don't use keepass". Yubiker adds a secret key to the user password. It's increasing the security by 160 bits against offline attacks (provided that its RNG is not flawed). – eli Apr 22 at 17:39
  • 1
    The notion that users would start using weaker passwords upon enabling 2FA due to a false sense of security is a weak one. A provider can mandate strict master password requirements, if it's so concerned. If not done so, in the name of "user convenience", it's are already on the compromise path. Adding Yubikey adds value as now the attacker needs another token even if they have access to the useless-without-it encrypted database vault. – Mohnish May 9 at 17:39

The Yubikey in this case is not MFA because the challenge-response mode does not require the use of a passcode in addition to the CR output. This is why a yubikey will often type gibberish into text fields with a user accidentally knocks the side of their token. Operating in this mode, the Yubikey is nothing more than an automated keyboard for outputting your password.

Now, what's interesting is that the database system KeePassXC is actually not updating their challenge to Yubikey except for when the database is saved. So if your database is only read from time to time with no changes, then the expected challenge does not change. What this means is that the Yubikey will return the same response value because the authentication system is not asking for a new response. In my limited understanding of the application, this is a limitation that KeePassXC could change, but has not for some reason.

Yubico Information on Challenge-Response mode:


What this means is...if you commit to the practice of saving your KeePassXC database each time it runs, then you can still trust the use of the Yubikey even with a keylogger. The database will expect a new response every time it is decrypted in this scenario and the previous response will not work. However, this will require high diligence on your part as the user and may not be desirable over a long period of time.

| improve this answer | |
  • "does not require the use of a passcode" - Unlocking the database requires a password. It's not relevant that using the yubikey itself doesn't require a separate password. Possession of the yubikey is the "weak second factor" in this case (weak because it's not a unique random challenge every time). – AndrolGenhald Jan 12 '19 at 17:31
  • I’ll give you that. The weakness as pointed as out is in the implementation of the Challenge from the software, not the Yubikey. – Connor Peoples Jan 12 '19 at 17:33
  • 3
    "this is a limitation that KeePassXC could change" - Changing the challenge every time you open the database would require rewriting the database every time it's opened, as the response to the challenge is mixed into the master key (otherwise it would be easy to bypass it, and it'd be basically meaningless). Even if they did this, it's not clear it would be an improvement, as the attacker may still have access to the old database and the old response to the challenge. All that's necessary to break it is to have access to 1 instance of the database and the corresponding challenge response. – AndrolGenhald Jan 12 '19 at 17:33

Assuming an attacker has access to my KeePassXC database and perhaps even installed a keylogger on my system, the additional YubiKey is useless in this case, am I right here?

Yes, but maybe not for the reason you're thinking. If an attacker has malware running on your system, you should assume your passwords are compromised the second you unlock the database, no matter how many factors that requires. Most "keyloggers" nowadays do a lot more than simple keylogging.

Even if all the malware is doing is logging keystrokes (and assuming that logging includes the yubikey input) all the attacker needs is the KeePass database, your password, and the HMAC-SHA1 response corresponding to that database instance. Even if KeePassXC decided to rewrite the database with a new challenge every time it was unlocked, this wouldn't really change anything in this case, the attacker can still get all 3.

| improve this answer | |
  • To put it in a nutshell: If I've already a relatively strong master password, the additional YubiKey does not really add much security, right? – Aliquis Jan 13 '19 at 8:50
  • 1
    @Aliquis I would view it as more of an extension to the password that automatically changes every time you save the database. Not entirely useless if you don't want to have to remember a password with 100+ bits of entropy, but also not really a true second factor. If you already have a very strong master password though, and you don't reuse that password for any other purpose, I would say that the benefit is probably very marginal. – AndrolGenhald Jan 13 '19 at 16:54

Yes it is reasonable (under some additional assumptions).

While very little can be done against local malware (as explained above) there are also other attack vectors to be aware of.

Mind your unlocking password leaks to cameras around you everywhere you use your laptop.

With physical hardware key there is one more layer of security. As laptop and hardware key typically travel and are seized together, this only makes sense if the hardware key itself is protected (can't be plugged and used by anyone).

| improve this answer | |
  • A camera in your room looking at your display is not in any way related to the question at hand. It's not a threat that can be mitigated by MFA. – MechMK1 Nov 26 '19 at 7:47
  • @MechMK1 I do agree my answer is out of scope now as I re-read the question. Anyway :) passwords being typed in do leak on ubiquitous cameras. Hardware key adds additional layer of security. Either by being a 2nd factor to a leaked password or by completely getting rid of the password typing, depending on circumstances. – qertoip Nov 27 '19 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.