I use a Windows 10 PC and an Android phone with Keepass.

I would like to add a second factor on top of my master password that works with both Windows 10 and my Android phone.

Between the two support methods of authentication, which one is more secure?

  1. Yubikey + Keepass 2 using Challenge/Response
  2. Yubikey + Keepass 2 using OTP

Thanks in advance.

  • 1
    Security is not really binary. You need to ask 'Is X secure against Y threats' otherwise it's difficult to answer with any meaning.
    – Steve
    Commented Mar 26, 2019 at 16:25
  • I am not aware of what weaknesses OTP has nor am I aware of the weaknesses of Challenge/Response has as I am asking this question. I am wondering which one puts more obstacles in front of an attacker. In other words, which one makes it most difficult for an attacker to decrypt the Keepass database either through brute force or other known weaknesses. Commented Mar 26, 2019 at 18:44

2 Answers 2


One important difference between OTPs and challenge/response schemes is that the first can be spoofed, and the second cannot. Suppose somebody sets up a phishing UI for KeePass, and you enter your password into it without realizing that it's not the legit one. The attacker realizes that the password isn't enough, you have MFA enabled. So far, so good.

If you use OTP, though, all the attacker needs to do is show the usual OTP entry box. You tap your Yubikey, it sends the OTP to the attacker, attacker forwards it to KeePass, and boom they've got access to your KeePass vault. If you instead use Challenge/Response, then the Yubikey's response is based on the challenge from the app. The attacker doesn't know the correct challenge to send for KeePass, so they can't spoof it.

Note that this distinction probably doesn't matter that much for a thick-client local app like KeePass, but it definitely matters for anything that does remote authentication. For example, if you're logging into a web app like Gmail, a phishing page can spoof the login UI and the OTP UI just fine. However, a phishing page cannot spoof the challenge/response flow, because that's based on the actual site being visited, and your browser (and therefore the Yubikey) will send a different challenge even if it looks the same to you.

In fact, challenge-response systems like this are the only method I know of that provides pretty strong security against phishing attacks. Everything else involving a true second factor - OTP, SMS, even push notifications - can be spoofed, and you will take the approve the authentication check just like normal because, as far as you know, you are logging in just like normal.

  • 3
    "The attacker doesn't know the correct challenge to send for KeePass, so they can't spoof it." [citation needed]. If we assume there's a MitM sitting between KeePass and the Yubikey, it can just forward the challenge. If you're thinking of how U2F (or webauthn) prevents spoofing, it's because it requires trust in the browser; the browser tells the token what domain name is used, the token includes that in the signed data, and the server checks the signature. The challenge-response used by KeePass is just a random value sent to the token to be HMAC'd. Commented May 25, 2019 at 1:40
  • @AndrolGenhald Fair enough, but if you're envisioning a MitM between the user's application and their USB port (or NFC or any other hardware), it's already game over for security. U2F probably wouldn't be secure in that scenario either. With that said, I was envisioning a malicious app that pretends to be KeePass in order to trick you into entering your credentials into it. I don't know exactly how KeePass generates its keys when using challenge/response, but I'd hope that it's done in a way such that a malicious app cannot derive the key unless it presents the right challenge first.
    – CBHacking
    Commented May 29, 2019 at 21:54
  • Could you clarify the threat model in your answer then? "You tap your Yubikey, it sends the OTP to the attacker, attacker forwards it to KeePass" makes it sound like there is a MitM between the Yubikey and KeePass, but you offered Challenge/Response as a defense against it. Besides the extra entropy offered by Challenge/Response, I'm having a hard time coming up with a threat model where it's definitely better than OTP. Commented May 30, 2019 at 0:17
  • @AndrolGenhald The attacking program can relay credentials (including an OTP) without having a MitM position. When a Yubikey is used in OTP mode, it just acts like a keyboard, sending input to whatever program has focus. The attacker program isn't sitting between the user and the destination, isn't intercepting anything; the attacker program has input focus so it IS the destination. It then just relays that data to the target, essentially pretending to be the user (but again, not actually being between the user and the target, just forwarding a message).
    – CBHacking
    Commented Mar 15, 2020 at 13:21

In my opinion "Keepass 2 using OTP" can not be "secure". Why?

OTP can not be used to encrypt data

Keepass encrypts data and the problem with encrypted data is, that you encrypt the data because you want to protect it against offline attacks. S.o. gets access to the data in the encrypted form and you want to avoid that the attacker can read it in clear text. But if the attacker has the encrypted data, he can run offline brute force attacks. And HOTP, creating 6 or 8 digit numbers do not realy add a big deal to protecting from offline attacks. It simply can add 6 digits to your password! This is fine for online authentication, when the account is blocked after a certain amount of failed tries. But there is no sense in using OTP to derivate encryption keys from.

The thing with OTP is, it is so short because it can be easily used for authentication, because everybody can type it in everywhere. This is cool - but only for the intended use cases!

I would not recommend to use OTP for keepass!

Using Challenge Response

Using challenge response does not have this limitation. Don't get me wrong, OTP has it's right to exist! And the problem with challenge response is: you need drivers! So there are authentication scenarios where OTP is better (not more secure!) than challenge response.

But back to keepass 2 and the dirvers. Well, with keepass this is no problem, because you obviously have them anyways. The Challenge Response mode of the Yubikey uses a symmetric secret key. You can send a challenge to the yubikey, it will create an hmac from the challenge and the secret key and respond with a 256bit return value. Now, you need the same challenge and the same secret key to always create the same return value. And obviously the return value is used as the encryption key (well actually the secret key is used as encryption key, but it is stored encrypted with the response value) But bottomline, you need the secret key to decrypt the data. As we are talking different key length here (than a 6 digit number), the secret key is as difficult to brute force as the AES encryption key itself. Read here: http://richardbenjaminrush.com/keechallenge/#using

I would recommend using Challenge/Response!

Disclaimer: Of course I did no code review or any in depth analysis. This is simply an evaluation from the basic official concepts of the two mechanism!

  • Thank you for the detailed explanation. Commented May 21, 2019 at 7:48
  • My understanding is that the KeePass OTP plugin gets around the brute-forcing attack you mention by requiring 3 successive OTP challenges (so an 18 character number). That said, I still don't understand mathematically how this helps encrypt the KeePass database. How would you know which segment of the original secret to use? Wouldn't you have to store the secret in plain text with the encrypted vault?
    – nightpool
    Commented Mar 31, 2021 at 15:58
  • @nightpool I do not know this either. It could be implemented this way: The secret key is contained in the encrypted data.The encryption key is encrypted with the OTP(1), OTP(2), OTP(3). And maybe with OTP(2), OTP(3), OTP(4). And OTP(3), OTP(4), OTP(5)... When you now try to decrypt the data and enter 3 consecutive OTP values, the application could try to decrypt the encryption key with the given OTP values. After successful decryption, the application needs to re-encrypt the encryption key with new consecutive OTP values.
    – cornelinux
    Commented Mar 31, 2021 at 19:30
  • isn't there an infinite number of OTP(1..3) values? how could you tell ahead of time which consecutive sequence the user would use?
    – nightpool
    Commented Apr 1, 2021 at 20:06
  • Yes, there is. This is why HOTP can get out of sync (see RFC4226). Using such an encryption method would mean the software needs to anticipate how many blank keypresses the user could produce without decrypting. As I said, OTP is not recommended for encryption. Disclaimer: I do not know how keypass actually does it. But there are not a lot of possibilies.
    – cornelinux
    Commented Apr 2, 2021 at 6:15

You must log in to answer this question.

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