In addition to my question: How many known time/result combinations does it take to guess a HOTP/TOTP secret?.

I've read often that TOTP is more secure than HOTP. One example:

TOTP provides higher security due to its time-based nature, reducing the window of opportunity for an attacker. If the company requires stricter security, TOTP might be the preferred option, especially as a second authentication factor for step-up authentication. - https://www.descope.com/blog/post/totp-vs-hotp

But I tend to disagree. I think that HOTP is more secure. Time is actually something that an attacker is much more likely to know. Especially when you can see a generated code either typed in by the user in a non-masked input field, fetched through MitM, or seen in a generation app by means of shoulder surfing. A counter is something the attacker is much less likely to be able to know, unless it's a a bad implementation of counters such as starting at 0 and doing +1 every time, then it becomes suddenly very brute-force-able. Or unless there is a bad implementation in a software generator app and the counter is just extractable from memory or disk. Which is much harder than simply knowing the time of generation.

I did see an custom implementation of a combined HOTP and TOTP recently which seems even stronger than HOTP or TOTP alone in my opinion as it uses two factors and makes is even harder to crack. However that's not commonly used and out of the two, TOTP is being the most commonly used (from personal experience).

I understand that from a management point of view (and therefore indirectly from an availability point of view) a out-of-sync time issue is much easier to manage and fix than a out-of-sync counter that needs resync. Despite that, is TOTP actually harder to crack and more secure than HOTP and why? If so, why is TOTP the preferred implemented method instead of HOTP?

1 Answer 1


A counter is something the attacker is much less likely to be able to know, unless it's a a bad implementation of counters such as starting at 0 and doing +1 every time

Just doing a +1 to the counter every time is fine (and is actually what the RFC says, because the counter doesn't have to be secret - only the seed does.

Assuming that you're not using a badly broken implementation, it shouldn't be realistically possible to "crack" either HOTP or TOTP (i.e, obtain the seed that would let you generate future codes), even if you have access to the counter/time and multiple valid codes.

If you're trying an online brute-force the code, then HOTP is going to be easier. With a standard six-digit code, then 1,000,000 attempts guarantees that you'll get the correct code (assuming the real user didn't try and authenticate in that period and increment the counter).

With TOTP 1,000,000 attempts gives you about a 63% chance of getting the right code, and you're never actually guaranteed to get a valid code unless you can brute-force the whole keyspace before the code changes (usually every 30s). However, it's complicated by the fact that many TOTP implementations will allow multiple valid codes at once (often the previous and next ones as well as the current one - which would increase your odds to 95%).

In either case, there isn't really a significant difference between the two of them. If an attacker can make a million attempts at guessing an OTP code then they can probably just keep going until they get a valid one.

But while the shorter lifespan of the codes doesn't make a huge difference in terms of brute-force protection, it can help protect against other attacks. For example, if you left your a hardware token unattended and an attacker was able to get a code from it without you noticing, they could potentially use that code hours later to login. With TOTP, they've only got a few minutes at most.

And as you mentioned in your post, synchronisation issues are much more of a problem with HOTP, whereas with TOTP you never need to worry about them as long as both clocks are reasonably correct. And that means if you implement HOTP, you also need to implement a mechanism to resynchronise the counters, which adds complexity (and more opportunities for things to go wrong).

So there's multiple factors in favour of TOTP (simpler to implement, harder to online brute-force, no synchronisation issues). In order for HOTP to be mor secure, you would need circumstances where an attacker has obtained the seed, but you have an implementation with some kind of bespoke complex and cryptographically secure counter that they're unable to obtain.

  • 1
    Very good example "unattended HOTP hardware token". Thank you.
    – Bob Ortiz
    Commented Nov 2, 2023 at 12:43

You must log in to answer this question.

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