How Authenticator Apps Work Offline: TOTP & HOTP | Bits To Billions

A website asks for a six-digit code. You open an app, and there it is, with a little timer running down - even in airplane mode. Nothing arrived: no text, no email, not even a notification. Nadia is on a night flight over the Atlantic, her phone offline for hours. In a data centre in Frankfurt, a server works out the very same six digits at the very same second - and when her timer runs out, both sides switch to a new code together. Two clocks that never speak, agreeing every thirty seconds. This is a defender's explainer: what is really inside the QR code you scan, how HMAC, HOTP and TOTP turn one shared secret into six digits, what happens when clocks drift, the rules a careful server follows, and what saves you when the phone is gone. Every load-bearing claim was checked against a primary source. Watch the whole Explained series:    • Authentication & Authorization Explained: ...   WHAT YOU'LL LEARN What the setup QR code really is: one otpauth:// line of text carrying a shared secret Base32, and why a 160-bit secret is 32 characters (RFC 4226 asks for at least 128 bits) Why the QR code is the key itself - and why you should treat it like a password Hash functions, and why the obvious 'secret in front of the message' recipe has a known flaw HMAC: the secret mixed in twice, inside and outside (RFC 2104) - and why SHA-1 collisions don't break it HOTP (RFC 4226): a counter, HMAC and dynamic truncation, worked through with the RFC's own test values Hardware keys and counter drift: the look-ahead window, and why a used code is never accepted again TOTP (RFC 6238): Unix time, 30-second time steps, and why TOTP is HOTP with the clock doing the counting Why authenticator apps work with no signal at all Clock drift and the validation window: why servers accept one step back, and no more Why a hand-set phone clock breaks your codes, and changing time zones never does The server's rules: one use per code, limited guessing (NIST's 100-attempt ceiling), encrypted secrets Why a TOTP secret can't be hashed like a password Why typed codes are not phishing-resistant, and where passkeys go further Backup codes (NIST 'look-up secrets'): how many, one use each, stored hashed Authenticator sync and backup: what it protects you from, and what it asks of your cloud account CHAPTERS 00:00 Intro 01:57 The shared secret 04:43 HMAC: the mixing recipe 07:43 HOTP: counting codes 10:51 TOTP: the clock as counter 13:45 When clocks disagree 16:37 The server's rules 19:23 Backup codes 21:47 Recap SOURCES RFC 6238, TOTP: Time-Based One-Time Password Algorithm (May 2011) - time steps, validation window, resynchronization, test vectors RFC 4226, HOTP: An HMAC-Based One-Time Password Algorithm (Dec 2005) - dynamic truncation, test values, look-ahead window, secret length, managing shared secrets RFC 2104, HMAC: Keyed-Hashing for Message Authentication (Feb 1997); Bellare, Canetti and Krawczyk, Keying Hash Functions for Message Authentication (CRYPTO '96) RFC 4648, Base-N encodings (Base32) Google Authenticator wiki, Key Uri Format (otpauth://) NIST SP 800-63B-4 (July 2025): OTP and look-up secret requirements, rate limiting, phishing resistance NIST SP 800-131A Rev. 2, and NIST's SHA-1 retirement announcement (15 Dec 2022) Google Account Help (Google Authenticator; backup codes); Google Security Blog on Authenticator sync (24 Apr 2023) Microsoft Support (Microsoft Authenticator); GitHub Docs (recovery codes); AWS IAM docs (virtual MFA devices) Yubico documentation (OATH-HOTP); M. Lombardi, NIST, on quartz clock accuracy OWASP Multifactor Authentication Cheat Sheet This is a defender's explainer. Risks are named only as far as the defences need - there is no attack tooling and no step-by-step here. Every load-bearing claim, number and date was checked against a primary source before recording. These are standalone explainers - one topic, one video, always from zero. Subscribe and you'll get the next one. #totp #2fa #mfa #cybersecurity #infosec