- Zásadní rozdíl ve vstupní proměnné: HOTP počítá hashe z monotónně rostoucího čítače C, zatímco TOTP nahrazuje C časovým krokem T odvozeným z epochálního času (CurrentUnixTime / 30).
- Přímá návaznost: TOTP je z matematického pohledu specializací HOTP:
TOTP(K, Time) = HOTP(K, T). Oba algoritmy využívají naprosto stejnou funkci dynamického zkrácení (Dynamic Truncation). - Rozhodující architektonický faktor: HOTP je stavový (servery musí při každém ověření zamykat a ukládat stav čítače do databáze). TOTP je bezstavový, což moderním cloudovým mikroslužbám umožňuje ověřovat tokeny napříč distribuovanými load-balancovanými klastry bez nutnosti centralizovaných zápisů.
Historické kořeny: Od proprietárních hardwarových tokenů k otevřeným webovým standardům
Na počátku tisíciletí vládly podnikovému dvoufázovému ověřování proprietární klíčenky jako RSA SecurID. Tato uzavřená a nákladná zařízení obsahovala vnitřní křemenné krystaly synchronizované s proprietárními podnikovými servery. Pokud chtěla organizace zajistit vícefaktorovou bezpečnost pro tisíce zaměstnanců, náklady na pořízení hardwaru a proprietární licence byly astronomické.
Aby se autentizace osvobodila od monopolu konkrétních dodavatelů, vzniklo konsorcium OATH (Initiative for Open Authentication), složené z předních technologických lídrů. Jeho cílem bylo vytvořit otevřené a bezplatné standardy IETF, které by mohl každý softwarový inženýr volně zkoumat, implementovat a auditovat:
HMAC-Based One-Time Password Algorithm. Navržen pro nízkovýkonové mikrokontroléry s fyzickým tlačítkem. Stisknutí tlačítka zvýší vnitřní čítač a zobrazí 6místný kód na LCD displeji.
Time-Based One-Time Password Algorithm. Vznikl v reakci na masivní nástup chytrých telefonů. Využitím síťové synchronizace času přes NTP v mobilních sítích TOTP zcela odstranil problémy s nesouladem stavu tlačítek.
Architektura HOTP (RFC 4226) a bajtová mechanika dynamického zkracování
Základní matematická definice HOTP je překvapivě stručná:
Rozbor parametrů:
K: Sdílený symetrický tajný klíč (obvykle binární sekvence 160 bitů / 20 bajtů dekódovaná z Base32).C: 8bajtový (64bitový) celočíselný čítač ve formátu big-endian.HMAC-SHA-1: Autentizační kód zprávy s klíčem produkující 20bajtový (160bitový) kryptografický otisk.
🔍 Jak dynamické zkrácení (Dynamic Truncation - DT) převádí 20 bajtů na 6 číslic:
Otisk HMAC-SHA1 obsahuje 160 bitů (20 bajtů). Získání 6 rovnoměrně rozložených desítkových číslic vyžaduje deterministický a vůči kolizím odolný mechanismus výběru, popsaný v sekci 5.3 specifikace RFC 4226:
Předpokládejme, že tajný klíč je ASCII řetězec "12345678901234567890" a čítač má hodnotu C = 0. Výsledný otisk HMAC-SHA1 v hexadecimálním tvaru je:
1. Poslední bajt je 0x71. Operace 0x71 & 0x0F = 0x01, tedy Offset = 1.
2. Bajty 1 až 4 jsou: 93 cf 18 50. Vynulování MSB dává 0x13cf1850, což v desítkové soustavě odpovídá číslu 332 339 280.
3. 332339280 mod 1000000 = 339280. Výsledný 6místný OTP kód je tedy 339280!
Evoluce TOTP (RFC 6238): Kouzlo časových kroků
HOTP vyžadoval udržovat čítač na klientovi a serveru v neustálém souladu. Na softwarových zařízeních však počítání stisků tlačítek vedlo k častým lidským chybám a desynchronizacím.
Standard RFC 6238 nahradil čítač C diskrétním časovým krokem T odvozeným přímo z unixového času:
- CurrentUnixTime: Počet sekund uplynulých od 1970-01-01 00:00:00 UTC.
- T0: Referenční bod začátku epochy (ve všech moderních nasazeních roven 0).
- X (Délka časového okna): Standardní doporučená délka činí 30 sekund.
- Zaokrouhlovací funkce ⌊ ⌋ (floor): Pro jakýkoli časový okamžik v daném 30sekundovém okně zůstává hodnota T invariantní. Například mezi unixovými sekundami 1728211200 a 1728211229 nabývá T naprosto stejného 64bitového celého čísla.
Binární serializace: Jakmile je hodnota T vypočtena, je zabalena do 8bajtového big-endian binárního bufferu (jehož paměťová struktura je zcela identická s čítačem C v HOTP). Jednotný vzorec se proto zjednodušuje na:
TOTP(K, Time) = HOTP(K, T)
Tato matematická elegance vysvětluje, proč autentizační aplikace generují nové kódy synchronně každých 30 sekund, aniž by musely s kýmkoli komunikovat nebo udržovat stav.
HS[31] & 0x0F); u SHA-512 (64bajtový otisk) z 63. bajtu (HS[63] & 0x0F). Nicméně u 99,9 % komerčních služeb (Google, Microsoft, GitHub, AWS) zůstává výchozím standardem SHA-1 z důvodu univerzální kompatibility se staršími mobilními klienty.
Podrobná srovnávací tabulka (HOTP vs. TOTP)
| Kritérium | HOTP (RFC 4226) | TOTP (RFC 6238) |
|---|---|---|
| Vstupní proměnná | Čítač událostí C (monotónně rostoucí) | Časový krok T (30sekundové okno Unix epoch) |
| Platnost tokenu | Neomezená (platí do jeho použití při přihlášení) | Přísně 30 sekund (automaticky expiruje) |
| Architektura serveru | Stavová (vyžaduje atomický zápis do databáze při každém přihlášení) | Bezstavová (nezávislé ověření přes čas NTP) |
| Riziko útoku přehráním (Replay) | Střední (odposlechnutý kód zůstává platný do prvního použití) | Minimální (omezeno pouze na zbývající sekundy v aktuálním okně) |
| Hlavní příčina selhání | Desynchronizace čítače (náhodné stisky tlačítka) | Časový posun hodin (rozdíl v systémovém čase telefonu) |
| Podporované kryptografické hashe | Výhradně HMAC-SHA-1 | HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512 |
| Rozšíření v oboru | Starší bankovní klíčenky, specializované fyzické brány | 99,9 % moderních webových autentizátorů |
Desynchronizace vs. časový posun: Technická řešení
V distribuovaných produkčních prostředích dochází k nevyhnutelným posunům mezi klienty a servery. Kryptografové proto navrhli explicitní kompenzační mechanismy pro zachování spolehlivosti:
Pokud uživatel stiskne tlačítko tokenu 5krát, aniž by kód odeslal, hodnota čítače na klientovi vzroste na C+5, zatímco na serveru zůstává C.
RFC 4226 stanoví, že server při ověřování prověřuje dopředné okno v rozsahu [C+1, C+s] (obvykle s hodnotou s=20). Pokud kód odpovídá kterékoli z těchto hodnot, server skočí vpřed a okamžitě sesynchronizuje čítač C na novou úroveň.
Kvůli síťové latenci nebo mírně opožděným hodinám telefonu (např. posun o 10 sekund) mohou kódy dorazit v sousedním časovém intervalu.
Produkční servery proto vyhodnocují pole tří oken: [T-1, T, T+1], což efektivně rozšiřuje toleranci přijetí na 90 sekund.
Když server ověřuje, zda se kód zadaný uživatelem shoduje s vypočítaným kódem, běžné porovnání řetězců (jako userOtp === serverOtp) skončí na prvním neshodném znaku. Útočník měřící nepatrné odchylky v síťové odezvě by tak mohl jednotlivé číslice postupně odhadnout. Podnikové backendy proto vynucují porovnání v konstantním čase (např. crypto.timingSafeEqual v Node.js), což postranní časové útoky zcela vylučuje.
Proč TOTP ovládl moderní internet
Jednoznačné vítězství TOTP nad HOTP napříč celým webem bylo způsobeno třemi klíčovými architektonickými výhodami:
V distribuovaných víceregionálních mikroslužbách může kterákoli instance serveru s časem synchronizovaným přes NTP ověřit TOTP tokeny bez dotazování či zamykání záznamů v centrální databázi.
Chytré telefony neustále kalibrují svůj systémový čas přes vysílače mobilních sítí a GPS, což eliminuje posun hodin bez nutnosti manuální správy hardwaru.
Kódy HOTP zůstávají platné neomezeně dlouho, dokud nejsou použity. Tokeny TOTP expirují po 30 sekundách, což automaticky znehodnocuje uniklé logy i pasivní odposlechy síťových paketů.
Vyzkoušejte si výpočty TOTP v reálném čase v nástroji 2FA-Tool
Podívejte se, jak se váš tajný klíč v Base32 převádí na dynamické 6místné kódy pomocí dynamického zkracování HMAC-SHA1. 100% offline přímo ve vašem prohlížeči.
📚 Související bezpečnostní návody
Návod na export účtů pomocí offline QR kódů a synchronizace s Google Cloud.
Pravidla shody, bezpečné uložení obnovovacích kódů a postupy nouzové obnovy.
Jak obnovit přístup k účtům Google, Microsoft, Steam, Binance, Apple a Discord.