34

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?

3
  • 1
    @sir-muffington could you please share your rationale for this comment? it's one of only a handful of (apparently) independent programs that supports argon2 across multiple host operating systems .. can you recommend any other options? (memory-hard password kdf with a separate keyfile, android, windows and linux are my req's .. mac and iphone would be nice-to-have)
    – brynk
    Commented Jan 2, 2022 at 1:58
  • @brynk this was meant as a neutral, objective comment. Have you checked out KeePass? It should fit if not all, at least most of the criteria. It even had a bug bounty set by the EU itself. Commented Jan 2, 2022 at 21:07
  • 6
    KeePassXC is under active development. Only its predecessor KeePassX has been discontinued. Commented Jan 6, 2022 at 12:30

6 Answers 6

41
+500

KeePassXC developer here, I got directed to this thread and want to add some remarks.

The answer by Jeffrey from 1Password is technically accurate. The YubiKey is used in a mode which is slightly different from what it was designed for. KeePassXC presents a (pseudo-)random challenge (the database's master seed, which changes every time you re-encrypt, i.e., save your database) to the YubiKey and gets a unique response in return. This response is then used to enhance your decryption key by hashing and transforming it together with your password and (optionally) your key file.

So, a YubiKey for your KeePassXC database isn't really a second factor in the sense of authentication (we are doing offline encryption, not online authentication after all), but it definitely makes your key stronger. So, this is where I think that, although his technical description is correct, Jeffrey's conclusion is wrong. Using a YubiKey in this way is not a hazard, but actually offers some unique security benefits:

  1. It adds 160 pseudo-random bits to your password, which on its own is already stronger than most users' passwords (especially considering that most passwords are vulnerable to dictionary attacks). Used in combination with a strong password or passphrase and Argon2 as your KDF, it makes your database very resilient against any kind of brute-force attack. As an attacker, you are probably better off guessing the transformed 256-bit AES key instead.
  2. Adding a YubiKey keeps your database secure even if your actual password gets leaked somehow. This is the same reason why people use key files as soft tokens. A YubiKey is much more secure than a key file, however, because it is a separate device that cannot be compromised and it performs a cryptographic calculation based on a hidden secret key, whereas a key file contains the secret in plaintext. In the case of a key file, I would actually concur with Jeffrey that it may give users a false sense of security, but a YubiKey is different and almost impossible to use incorrectly.
  3. It gives your otherwise static symmetric encryption scheme what you may call "pseudo forward (or backward?) secrecy". Even if an attacker gets hold of both your password and a particular YubiKey response, they will be unable to decrypt any previous and even any future version of your database. Of course, you will have to change all exposed passwords in that case anyway, but it adds additional protection against compromise of any new passwords you add between the time of the attacker breaking into your database and you noticing the exposure and it also keeps previous passwords that are not in the exposed database anymore secure (probably not that valuable, but may actually be helpful in some cases).
  4. The YubiKey response does not appear on-screen and does not use a conventional keyboard interface. This is not really a security property, but it can sometimes help if your system is compromised with a generic key logger that does not intercept all USB inputs. Of course, a more specialised key logger can totally intercept the YubiKey response, and hence I would not trust this as a defence measure, but in some cases it may help. In general, however, expect your data to be lost if you have malware on your system. The only thing you can try in that case is damage mitigation, but overall, a compromised system is not your system anymore, so don't expect there to be any effective counter measure against key loggers other than not getting one in the first place.

I updated our FAQ to be a bit more precise on the terminology and included some additional details as well.

1
  • Thank you very much for taking your time to write so detailed answers and updating your products' FAQ! Regarding malware I guess that's where you would prefer to use immutable systems these days, so Linux with ostree (Fedora Silverblue, Endless OS, Steam OS sadly is unencrypted at the time of writing) should improve your security. Everyone feel free to correct me.
    – LiveWireBT
    Commented Jan 14, 2023 at 5:20
16

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.

3
  • 11
    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
    Commented Apr 22, 2020 at 17:39
  • 5
    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
    Commented May 9, 2020 at 17:39
  • 1
    Why doesn't 1Password or Keepass use the HSM public key encryption features of the Yubikey to encrypt/decrypt the database as a second provider of key material? Wouldn't that be equivalent to 2fa—it requires two secrets, one from the user's password and one kept custodially on the Yubikey, to decrypt the database—without letting the key material ever leave the Yubikey? That would provide true forward secrecy without necessitating a complicated challenge/response scheme. And then you could use a simple envelope scheme to enroll multiple yubikeys (keep a single master key encrypted twice)
    – nightpool
    Commented Mar 10, 2023 at 20:33
6

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:

https://www.yubico.com/products/services-software/personalization-tools/challenge-response/

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.

3
  • 1
    "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). Commented Jan 12, 2019 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. Commented Jan 12, 2019 at 17:33
  • 5
    "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. Commented Jan 12, 2019 at 17:33
3

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

2
  • 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.
    – user163495
    Commented Nov 26, 2019 at 7:47
  • 2
    @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
    Commented Nov 27, 2019 at 13:28
1

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.

2
  • 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
    Commented Jan 13, 2019 at 8:50
  • 3
    @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. Commented Jan 13, 2019 at 16:54
0

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?

As stated:

  • If the attacker has only the database, it protects against dictionary attacks, brute-force attacks and attacks based on password re-use.
  • If the attacker has the database and has installed a keylogger, it maybe adds a little protection in some edge cases. But if the attacker knows what it's doing, you're screwed.

In addition, regardless of the attack scenario, it's reasonable to use a Yubikey so you don't have to worry about forgetting your password ;)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .