- Het fundamentele verschil in invoer: HOTP berekent hashes op basis van een monotoon oplopende teller C, terwijl TOTP C vervangt door een discrete tijdstap T (HuidigeUnixTijd / 30).
- Directe overerving: TOTP is wiskundig gezien een specialisatie van HOTP:
TOTP(K, Tijd) = HOTP(K, T). Beide algoritmen gebruiken exact dezelfde functie voor dynamische truncatie. - De doorslaggevende architectuurfactor: HOTP is stateful (servers moeten tellers bij elke validatie vergrendelen en naar schijf schrijven). TOTP is stateless, waardoor moderne cloud-microservices tokens kunnen valideren over gedistribueerde load-balanced clusters zonder gecentraliseerde databaseschrijfacties.
Historische wortels: van gesloten hardwaretokens naar open webstandaarden
Begin jaren 2000 werd tweefactorauthenticatie in het bedrijfsleven gedomineerd door gesloten hardwaretokens zoals RSA SecurID. Deze dure, propriëtaire apparaten bevatten interne kwartskristallen die gesynchroniseerd waren met propriëtaire bedrijfsservers. Als een organisatie duizenden werknemers wilde voorzien van multifactorbeveiliging, waren de hardware- en licentiekosten torenhoog.
Om authenticatie te bevrijden van gesloten leveranciers, richtten marktleiders het OATH (Initiative for Open Authentication)-consortium op om open, royaltyvrije IETF-standaarden te ontwikkelen die elke softwareontwikkelaar vrij kon inzien, implementeren en controleren:
HMAC-Based One-Time Password Algorithm. Ontworpen voor microcontrollers met een laag stroomverbruik en fysieke drukknoppen. Een druk op de knop verhoogt een interne teller en toont een 6-cijferig token op een lcd-schermpje.
Time-Based One-Time Password Algorithm. Ontworpen tijdens de opkomst van smartphones. Door gebruik te maken van tijdsynchronisatie via NTP via het mobiele netwerk, elimineerde TOTP statusverschillen door fysieke knoppen volledig.
HOTP (RFC 4226)-architectuur & bytemechanisme van dynamische truncatie
De wiskundige kerndefinitie van HOTP is bedrieglijk beknopt:
Verklaring van parameters:
K: Gedeelde symmetrische geheime sleutel (doorgaans een gedecodeerde Base32 binaire reeks van 160 bits / 20 bytes).C: 8-byte (64-bit) big-endian integer-teller.HMAC-SHA-1: Keyed-hash berichtauthenticatiecode die een cryptografische digest van 20 bytes (160 bits) genereert.
🔍 Hoe dynamische truncatie (DT) 20 bytes omzet in 6 cijfers:
Een HMAC-SHA1-digest bevat 160 bits (20 bytes). Het extraheren van 6 uniforme decimale cijfers vereist een deterministisch, botsingsbestendig selectiemechanisme dat is gedefinieerd in sectie 5.3 van RFC 4226:
Stel dat de geheime sleutel ASCII "12345678901234567890" is en teller C = 0. De resulterende HMAC-SHA1-digest in hexadecimaal is:
1. De laatste byte is 0x71. 0x71 & 0x0F = 0x01, dus Offset = 1.
2. Bytes 1 t/m 4 zijn: 93 cf 18 50. Het wissen van de MSB levert 0x13cf1850 op, wat in decimaal gelijk is aan 332.339.280.
3. 332339280 mod 1000000 = 339280. De resulterende 6-cijferige OTP is 339280!
De evolutie naar TOTP (RFC 6238): de magie van de tijdstap
Bij HOTP moest de teller op de client synchroon worden gehouden met die op de server. Op softwareapparaten zorgt het tellen van toetsaanslagen of knopdrukken voor onvermijdelijke menselijke fouten.
RFC 6238 verving teller C door een discrete tijdstap T, rechtstreeks afgeleid van de Unix epoch-klok:
- HuidigeUnixTijd: Seconden verstreken sinds 1970-01-01 00:00:00 UTC.
- T0: Referentiepunt voor epoch-initialisatie (standaard 0 in alle moderne toepassingen).
- X (Tijdstapvenster): Standaard aanbevolen duur van 30 seconden.
- Afrondingsfunctie ⌊ ⌋ (Floor): Voor elk tijdstempel binnen een venster van 30 seconden blijft T constant. Tussen bijvoorbeeld epoch-seconden 1728211200 en 1728211229 levert T exact hetzelfde 64-bits gehele getal op.
Binaire serialisatie: Zodra T is berekend, wordt deze verpakt in een 8-byte big-endian binaire bytebuffer (qua geheugenstructuur identiek aan teller C in HOTP). Daardoor vereenvoudigt de uniforme formule tot:
TOTP(K, Tijd) = HOTP(K, T)
Deze wiskundige elegantie verklaart waarom authenticator-apps tokens elke 30 seconden synchroon vernieuwen zonder dat er permanente statussynchronisatie nodig is.
HS[31] & 0x0F); bij SHA-512 (64-byte digest) uit byte 63 (HS[63] & 0x0F). Op 99,9% van de commerciële websites (Google, Microsoft, GitHub, AWS) blijft SHA-1 echter de universele standaard vanwege compatibiliteit met oudere mobiele clients.
Uitgebreide vergelijkingsmatrix (HOTP vs. TOTP)
| Dimensie | HOTP (RFC 4226) | TOTP (RFC 6238) |
|---|---|---|
| Invoervariabele | Gebeurtenisenteller C (monotoon oplopend) | Tijdstap T (Unix-epochvenster van 30 seconden) |
| Geldigheidsduur van token | Onbepaald (geldig tot verbruikt bij volgende login) | Strikt 30 seconden (vervalt automatisch) |
| Serverarchitectuur | Stateful (vereist atomair wegschrijven naar database per login) | Stateless (onafhankelijke verificatie via NTP) |
| Risico op replay-aanvallen | Matig (onderschept token blijft geldig tot het gebruikt wordt) | Minimaal (beperkt tot resterende seconden in huidig venster) |
| Belangrijkste storingsfactor | Tellersynchronisatieverlies (per ongeluk indrukken van knop) | Tijdsafwijking (klokafwijking op mobiele client) |
| Ondersteunde cryptografische hashes | Uitsluitend HMAC-SHA-1 | HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512 |
| Toepassing in de praktijk | Verouderde banktokens, fysieke toegangscontrole | 99,9% van moderne online authenticators |
Desynchronisatie vs. tijdsafwijking: technische oplossingen
In gedistribueerde productieomgevingen treedt onvermijdelijk afwijking op tussen clients en servers. Cryptografen hebben hiervoor specifieke tolerantievensters ontworpen om betrouwbaarheid te waarborgen:
Als een gebruiker 5 keer op zijn tokenknop drukt zonder in te loggen, staat de teller van de client op C+5 terwijl de server nog op C staat.
RFC 4226 schrijft voor dat de server bij authenticatie een vooruitkijkvenster berekent over [C+1, C+s] (meestal s=20). Als er een overeenkomst wordt gevonden, springt de server vooruit en synchroniseert deze teller C onmiddellijk.
Door netwerklatentie of klokafwijking op het apparaat van de client (bijv. een telefoonklok die 10 seconden achterloopt), kunnen tokens in aangrenzende tijdstappen binnenkomen.
Productieservers evalueren een matrix van 3 vensters: [T-1, T, T+1], waardoor het acceptatievenster effectief wordt verruimd naar 90 seconden.
Wanneer servers controleren of de door de gebruiker ingevoerde code overeenkomt met de berekende code, stopt een naïeve stringvergelijking (zoals userOtp === serverOtp) direct bij het eerste afwijkende teken. Een aanvaller die microscopisch kleine roundtrip-tijden via het netwerk meet, kan cijfers stapsgewijs reconstrueren. Zakelijke backends dwingen vergelijkingen in constante tijd af (zoals crypto.timingSafeEqual in Node.js) om timingaanvallen via side-channels te voorkomen.
Waarom TOTP het moderne internet veroverde
De doorslaggevende overwinning van TOTP op HOTP werd aangedreven door drie fundamentele architectuurvoordelen:
In gedistribueerde microservices over meerdere regio's kan elke serverinstantie met een NTP-gesynchroniseerde klok TOTP-tokens valideren zonder een centrale database te raadplegen of te vergrendelen.
Smartphones synchroniseren hun systeemklok continu via zendmasten en GPS, waardoor klokafwijkingen worden geëlimineerd zonder fysiek onderhoud aan hardware.
HOTP-tokens blijven oneindig geldig tot ze gebruikt worden. TOTP-tokens vervallen binnen 30 seconden, waardoor gecompromitteerde logs en passief afgeluisterde pakketten automatisch waardeloos worden.
Ervaar real-time TOTP-berekeningen in 2FA-Tool
Zie hoe uw geheime Base32-sleutel wordt getransformeerd in dynamische 6-cijferige codes via HMAC-SHA1 dynamische truncatie. 100% offline in uw browser.
📚 Gerelateerde beveiligingshandleidingen
Hoe u 2FA-accounts overzet naar een nieuwe smartphone met offline QR-codes en cloud-synchronisatie.
Beveiligingsregels, herstelcodes opslaan, interactie met SSH-sleutels en herstelprocedures.
Herstel toegang tot Google, Microsoft, Steam, Binance, Apple en Discord.