- Den grunnleggende inndataforskjellen: HOTP beregner hasher fra en monotont økende teller C, mens TOTP erstatter C med et epoke-tidssteg T (CurrentUnixTime / 30).
- Direkte arv: TOTP er matematisk sett en spesialisering av HOTP:
TOTP(K, Time) = HOTP(K, T). Begge algoritmene benytter nøyaktig samme dynamiske trunkeringsfunksjon (Dynamic Truncation). - Arkitektonisk avgjørende faktor: HOTP er tilstandsavhengig (stateful) (servere må låse og lagre tellere på disk ved hver validering). TOTP er tilstandsløs (stateless), noe som gjør at moderne distribuerte mikrotjenester i skyen kan validere koder på tvers av lastbalanserte klynger uten sentraliserte databaseriv-operasjoner.
Historiske røtter: Fra proprietære maskinvarebrikker til åpne nettstandarder
På begynnelsen av 2000-tallet var tofaktorautentisering for bedrifter dominert av proprietære sikkerhetsbrikker (key fobs) som RSA SecurID. Disse lukkede og kostbare enhetene inneholdt interne kvartskrystaller som var synkronisert med proprietære bedriftsservere. Hvis en organisasjon ønsket å gi flerfaktorbeskyttelse til tusenvis av ansatte, var anskaffelses- og lisenskostnadene enorme.
For å frigjøre autentisering fra proprietære leverandører ble OATH (Initiative for Open Authentication)-konsortiet dannet av bransjeledere. Målet var å levere åpne, royaltyfrie IETF-standarder som enhver programvareutvikler fritt kunne inspisere, implementere og revidere:
HMAC-Based One-Time Password Algorithm. Skreddersydd for strømgjerrige mikrokontrollere med fysiske trykknapper. Et knappetrykk øker en intern teller og viser en 6-sifret kode på en LCD-skjerm.
Time-Based One-Time Password Algorithm. Utviklet i takt med smarttelefonenes gjennombrudd. Ved å utnytte tidssynkronisering over mobilnettet via NTP, eliminerte TOTP feilkilder knyttet til fysiske knapper og tilstandsavvik fullstendig.
HOTP (RFC 4226)-arkitektur og bytemekanikk i dynamisk trunkering
Den matematiske kjerneformelen for HOTP er bemerkelsesverdig presis:
Gjennomgang av parametere:
K: Delt symmetrisk hemmelig nøkkel (vanligvis en Base32-dekodet 160-bit / 20-byte binærsekvens).C: 8-byte (64-bit) big-endian heltallsteller.HMAC-SHA-1: Nøkkelbasert meldingsautentiseringskode som produserer et 20-byte (160-bit) kryptografisk sammendrag (digest).
🔍 Slik konverterer dynamisk trunkering (DT) 20 bytes til 6 sifre:
Et HMAC-SHA1-sammendrag inneholder 160 bits (20 bytes). For å trekke ut 6 jevnt fordelte desimalsifre kreves en deterministisk, kollisjonsresistent utvalgsmekanisme definert i seksjon 5.3 av RFC 4226:
Anta at den hemmelige nøkkelen er ASCII "12345678901234567890" og telleren C = 0. Det resulterende HMAC-SHA1-sammendraget i heksadesimal form er:
1. Den siste byten er 0x71. 0x71 & 0x0F = 0x01, så Offset = 1.
2. Bytene 1 til 4 er: 93 cf 18 50. Nullstilling av MSB gir 0x13cf1850, som i desimalform tilsvarer 332 339 280.
3. 332339280 mod 1000000 = 339280. Den resulterende 6-sifrede engangskoden (OTP) er 339280!
Utviklingen av TOTP (RFC 6238): Tidsstegets magi
HOTP krevde at telleren på klienten var i synk med serveren. På programvareenheter førte utilsiktede tastetrykk eller generering av koder til hyppige desynkroniseringsfeil.
RFC 6238 erstattet teller C med et diskret tidssteg T utledet direkte fra Unix-epokeklokken:
- CurrentUnixTime: Antall sekunder som har gått siden 1970-01-01 00:00:00 UTC.
- T0: Referanse for epokeinitialisering (standardverdi er 0 i alle moderne systemer).
- X (Tidsstegvindu): Standard anbefalt varighet på 30 sekunder.
- Avrundingsfunksjon ⌊ ⌋ (Floor): For ethvert tidsstempel innenfor et 30-sekunders vindu forblir T uendret. For eksempel gir epokesekundene 1728211200 og 1728211229 nøyaktig samme 64-bit heltall.
Binær serialisering: Når T er beregnet, pakkes det inn i en 8-byte big-endian binærbuffer (identisk i minnestruktur med teller C i HOTP). Følgelig forenkles den forente formelen til:
TOTP(K, Time) = HOTP(K, T)
Denne matematiske elegansen forklarer hvorfor autentiseringsapper ruller over koder synkront hvert 30. sekund uten behov for tilstandslagring på tvers av enheter.
HS[31] & 0x0F); i SHA-512 (64-byte digest) hentes den fra byte 63 (HS[63] & 0x0F). På 99,9 % av kommersielle nettsteder (Google, Microsoft, GitHub, AWS) forblir imidlertid SHA-1 standarden av hensyn til bakoverkompatibilitet med eldre mobilklienter.
Omfattende sammenligningsmatrise (HOTP vs. TOTP)
| Dimensjon | HOTP (RFC 4226) | TOTP (RFC 6238) |
|---|---|---|
| Inndatavariabel | Hendelsesteller C (monotont økende) | Tidssteg T (30-sekunders Unix-epokevindu) |
| Kodens levetid | Ubegrenset (gyldig til den forbrukes ved neste innlogging) | Strengt 30 sekunder (ugyldiggjøres automatisk) |
| Serverarkitektur | Tilstandsavhengig (krever atomære databaseskrivinger per innlogging) | Tilstandsløs (uavhengig NTP-verifisering) |
| Eksponering for replay-angrep | Moderat (avlyttet kode forblir gyldig til den brukes) | Minimal (begrenset til gjenværende sekunder i gjeldende vindu) |
| Primær feilkilde | Teller-desynkronisering (utilsiktede trykk) | Tidsavvik (klokkeavvik på klientens telefon) |
| Støttede kryptografiske hasher | Kun HMAC-SHA-1 | HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512 |
| Bransjeadopsjon | Eldre bankbrikker, spesialiserte fysiske porter | 99,9 % av moderne nettbaserte autentiseringsapper |
Desynkronisering vs. tidsavvik: Tekniske mottiltak
I distribuerte produksjonsmiljøer vil klienter og servere uunngåelig oppleve tidsavvik. Kryptografer har utviklet eksplisitte kompensasjonsvinduer for å opprettholde pålitelighet:
Hvis en bruker trykker på brikkeknappen 5 ganger uten å sende koden, vil klientens teller nå C+5 mens serveren forblir på C.
RFC 4226 spesifiserer at serveren ved autentisering beregner et foroverseende vindu over [C+1, C+s] (vanligvis s=20). Hvis det oppstår treff, oppdaterer serveren telleren og synkroniserer C umiddelbart.
På grunn av nettverksforsinkelse eller tidsavvik på klientenheten (f.eks. at telefonens klokke henger 10 sekunder etter), kan koder ankomme i tilstøtende tidssteg.
Produksjonsservere evaluerer et 3-vinduers intervall: [T-1, T, T+1], noe som i praksis utvider akseptvinduet til 90 sekunder.
Når servere verifiserer om koden fra brukeren stemmer overens med den beregnede koden, vil naive likhetssjekker (som userOtp === serverOtp) avslutte ved første tegn som ikke matcher. En angriper som måler mikroskopiske tidsforskjeller i nettverksresponsen, kan gradvis gjette sifrene. Bedriftssystemer benytter derfor konstant-tids likhetssammenligninger (f.eks. crypto.timingSafeEqual i Node.js) for å avverge sidekanalsangrep basert på timing.
Hvorfor TOTP erobret det moderne internett
Den overbevisende seieren for TOTP over HOTP på tvers av nettet ble drevet av tre arkitektoniske fortrinn:
I distribuerte mikrotjenester på tvers av regioner kan enhver serverinstans med en NTP-synkronisert klokke validere TOTP-koder uten å spørre eller låse en sentralisert databasepost.
Smarttelefoner kalibrerer systemklokkene kontinuerlig via basestasjoner og GPS, og eliminerer dermed tidsavvik uten behov for manuell maskinvarevedlikehold.
HOTP-koder forblir gyldige på ubestemt tid til de brukes. TOTP-koder utløper innen 30 sekunder, noe som automatisk nøytraliserer lekkede logger og passiv pakkesniffing.
Opplev sanntids TOTP-beregninger i 2FA-Tool
Se hvordan din Base32-hemmelighet transformeres til dynamiske 6-sifrede koder via HMAC-SHA1 dynamisk trunkering. 100 % frakoblet i nettleseren din.
📚 Relaterte sikkerhetsveiledninger
Slik flytter du 2FA-kontoer mellom smarttelefoner med frakoblede QR-koder og skysynkronisering.
Sikkerhetskrav, lagring av gjenopprettingskoder, SSH-nøkler og nødprosedyrer.
Slik gjenoppretter du tilgang til Google, Microsoft, Steam, Binance, Apple og Discord.