1

Looking at the implementation of the Yubikey 4 HMAC-SHA1 mode for KeePassXC, I want to know:

Isn't the HMAC-SHA1 challenge response less secure than a 40+ character password?

From what I know, the challenge is hard-coded, so an attacker already has this. So the only secret is the response, which is 20bytes SHA1.

A normal 40 character password has 40*~7bits (stripping non printable / usable chars in ASCII) as usable secret. So it should be more secure as that results in a 280 bit secret versus 160bit SHA1.

Edit: Assuming both, the Yubikey and the normal Password secrets are created using true randomness. So we're not talking about the improvements over the typical "Password1234" passwords.

If I'm missing anything feel free to correct me.

proc
  • 13
  • 5
  • Is that "20bits SHA1" a typo, or is it a misunderstanding? 160 bits is perfectly fine. Also, **passwords** tend not to be perfectly random. – AndrolGenhald Sep 21 '18 at 19:18
  • ah, 20bytes, I'm sorry, typo; edit: password which is choosen by true randomness, at least as far as I can tell, not self imagined or such – proc Sep 21 '18 at 19:28
  • so we're not dealing with 20bytes "real" randomness vs the "typical" user password randomness – proc Sep 21 '18 at 19:30

1 Answers1

0

If the challenge is hard-coded, then yes, the random password is probably* more secure, but meaninglessly so. 128 bits is so far beyond our capability of brute-forcing that there's really no need to go higher unless you're concerned with very long term secrets. 256 bits can be justified with the generous assumption that quantum operations will eventually be as cheap as classical operations, but even in this case the 160 bits of HMAC-SHA1 is far from trivial.

(*) One method of avoiding timing attacks on string comparison is to compare a hash of each string, if this hash is 160 bits or smaller you're limited to that many bits of security regardless

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50