I'm looking into using a OTP solution.

HOTP is a OTP solution that is based on a HMAC with as hashing algorithm SHA-1. The standards defines it this way.

But... SHA1 (as we know) has been a weakness.

So, now i'm looking into using a hashing algoritme from the SHA-2 family as the hash for my HOTP solution. any thoughts on this?

Yes, the alternative could be using TOTP, there the RFC tells us that it is ok to use different hashing algoritmes.

Does the way that SHA1 is broken not effect the HMAC? The counter that HOTP uses increments each time. So collisions are not really a big problem.

But some feedback from you people would be very much appreciated!

  • You really like these hash based authentication protocols. You still need a secure transport layer after authentication: OWASP A9
    – rook
    Mar 24, 2013 at 16:51
  • Thank you for your response! I think that authentication protocols are interesting.
    – Anonymous
    Mar 24, 2013 at 18:41
  • Oah I agree, TLS-SRP is one of my favorites, its pretty new and unfortunately uncommon.
    – rook
    Mar 24, 2013 at 18:44
  • Oh yes! I've been looking into SRP this morning. Very interesting stuf indeed!
    – Anonymous
    Mar 24, 2013 at 18:48
  • If you are interested in implementing HOTP or TOTP with SHA-2 algorithms, the sample code on pages 11 and 12 of RFC6238 (TOTP) shows how to adapt the HOTP algorithm for other hash algorithms. It's very simple, all that's required is generalizing taking exactly the 19th byte from the HMAC result to taking the last byte as the offset. Jun 12, 2022 at 0:31

2 Answers 2


HMAC/SHA-1 is not broken. SHA-1 has a weakness with regards to collisions (and it is still "theoretical" since producing a collision for SHA-1, though conceptually easier than the generic attack, is still so expensive that nobody has computed one such collision yet). But HMAC resistance does not rely on resistance to collisions.

Indeed, HMAC is proven secure as long as the hash function which it uses is a Merkle-Damgård function which itself relies on an internal "compression function" which behaves like a PRF. This is rather technical. To make a long story short, the known weakness of SHA-1 voids the proof, but nobody knows how to turn that into a weakness on HMAC/SHA-1. Empirically, we have the example of MD4: MD4 is extremely broken with regards to collisions, with a near-zero cost (computing a collision for MD4 takes less time than actually hashing the two colliding messages to verify that it is, indeed, a collision), and HMAC/MD4 is also broken, but with a quite non-trivial cost of 258 plaintext/MAC pairs (and that's a forgery attack, not even a key recovery attack), making it utterly non-applicable in practice. If we have the same kind of ratio for SHA-1, then HMAC/SHA-1 is still very safe.

Nevertheless, HOTP can be used with any hash function but this requires "adaptations". On a general basis, thou shallt not fiddle with cryptographic algorithms. That being said, it is rather obvious (at least for a cryptographer) that replacing SHA-1 with "SHA-256 truncated to 160 bits" in HOTP will yield something which is equally secure (i.e. the detailed security analysis of HOTP fully applies with that alternate hash function). However, changing the hash function means that you can no longer test your implementation with regards to the published test values, and that's a big worry. Implementation bugs are a much more common source of practical vulnerabilities than cryptographic weaknesses.

Therefore, use HOTP with HMAC/SHA-1 and be happy. It is not broken.

  • Since TOTP builds on HOTP, it should be possible to use the TOTP test vectors to verify your implementation of HOTP with HMAC-SHA-2. So this worry isn't that big in practice. Mar 24, 2013 at 13:28
  • I'm sorry for the strong language, i fixed it in my posting. It has a weakness. Not been broken. So, i felt the same way "thou shallt not fiddle with cryptographic algorithms" so thats way i came here. To ask for advice. If i would like to use a hash from the SHA-2 family i should use TOTP. But as you say "it voids the proof". So using it is no longer "proofable" secure.
    – Anonymous
    Mar 24, 2013 at 18:43

If I understand it correctly, collision is not important in this case. From a big string (your secret) and the timestamp, you are generating a 6 digits OTP PIN, consisting only of numbers. You'll of course have an immense number of collisions! What will save you, is the fact that OTP changes continuously, and attacker needs to guess the static part of your PIN and username.

You must log in to answer this question.

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