Lion Cipher Lab
Build an HOTP and TOTP Validator From Scratch (and Break the Naive Ones)
- Identity & Access Management
- Advanced
- ~75 min
- Free · no account required
Why it matters
Every 2FA tutorial on the internet hands you a library and a QR code, so 'the code changes every 30 seconds' becomes the entire mental model — and that model is wrong in ways that cause real account takeovers. The bugs are never in the HMAC. They are in the verifier: no replay cache, so a code phished thirty seconds ago still works; no throttle, so a script can simply grind the 6-digit space; a drift window widened to shut up support tickets, which multiplies the number of live codes; a plain `==` where a constant-time compare belongs. Writing HOTP and TOTP yourself in fifty lines of…
What you'll learn
- HOTP (RFC 4226) implementation
- TOTP (RFC 6238) time-step validation
- HMAC dynamic truncation
- base32 secrets and otpauth:// provisioning URIs
- OTP replay prevention
- verification throttling and lockout
- constant-time comparison
- validating crypto against official RFC test vectors
Steps in this lab
- What a one-time password actually is, and why we build the SERVER half
- Set up: a folder, Python, and nothing else
- Write the core: HOTP, dynamic truncation, and TOTP
- Watch dynamic truncation happen, byte by byte
- Prove it: run the official RFC 4226 and RFC 6238 test vectors
- Write the server: enrolment, the otpauth:// URI, and a verifier you can cripple
- Bug 1 — no replay cache: the same live code works over and over
- Bug 2 — no throttle: do the arithmetic, then watch it happen
- Bug 3 — an over-generous drift window multiplies the live code space
- Bug 4 — comparing with == instead of hmac.compare_digest, and how much it really matters
- The judgment: when TOTP is right, when it is not, and what to ship