Hotp vs totp choices

[jinwatkins]

Wondering if HOTP is the right fit for a field team that authenticates only a few times a day. They sometimes have no network and want a code that works on demand. TOTP has been okay in other apps, but time skew and dead batteries have caused headaches. With HOTP, I like the “press for a code” idea, yet I’m worried about counters drifting when people mash the button. What are the trade-offs, and how do you prevent runaway counter issues in the real world?

[ricerick]

HOTP shines for intermittent use because codes don’t expire by clock—they’re event-driven. The trade-off is managing counter state. Use a modest resync window (say 10–20 steps for field scenarios), enforce throttling, and bump the server counter only on a verified hit inside that window. Provide a “resync” flow in support tools to test a few successive codes and catch up safely. When evaluating or demoing sequence behavior without affecting your live systems, this hotp generator enables you to generate the exact next codes and verify your backend logic. If your users authenticate constantly, TOTP can be simpler; for bursty, offline-friendly workflows, HOTP with sane windows is very practical.

[FoddyJin]

Adding a neutral note from day-to-day use: the button-mashing fear was real for us, but it didn’t materialize once we taught folks to press once and wait. The small resync window covered the rare extra press, and rate limiting muted brute-force risks. We also added a quick support script that asks for two consecutive codes to resync without exposing secrets. That balance kept offline access smooth and kept the ops team calm.