- Den grundläggande skillnaden i indata: HOTP beräknar hashar från en monotont ökande räknare C, medan TOTP ersätter C med ett tidssteg T härlett från epoktid (AktuellUnixTid / 30).
- Direkt arv: TOTP är matematiskt en specialisering av HOTP:
TOTP(K, Tid) = HOTP(K, T). Båda algoritmerna använder exakt samma dynamiska trankeringsfunktion (Dynamic Truncation). - Arkitektonisk avgörande faktor: HOTP är tillståndsbevarande (servrar måste låsa och skriva räknare till databas vid varje validering). TOTP är tillståndslöst (stateless), vilket gör att moderna molnmikrotjänster kan validera token över distribuerade, lastbalanserade kluster utan centraliserade databasskrivningar.
Historiska rötter: Från proprietära hårdvarutoken till öppna webbstandarder
I början av 2000-talet dominerades tvåfaktorsautentisering på företag av proprietära säkerhetsdosor som RSA SecurID. Dessa slutna, dyra enheter innehöll interna kvartskristaller synkroniserade med proprietära företagsservrar. Om en organisation ville erbjuda flerfaktorssäkerhet till tusentals anställda var hårdvaruanskaffningen och de proprietära licenskostnaderna astronomiska.
För att frigöra autentisering från proprietära leverantörer bildades konsortiet OATH (Initiative for Open Authentication) av branschledare för att ta fram öppna, royaltyfria IETF-standarder som alla programvaruutvecklare fritt kunde granska, implementera och analysera:
HMAC-Based One-Time Password Algorithm. Anpassad för energisnåla mikrokontrollers med fysiska tryckknappar. Ett tryck på knappen ökar en intern räknare och visar en 6-siffrig token på en LCD-skärm.
Time-Based One-Time Password Algorithm. Designad i takt med att smarttelefonsanvändningen exploderade. Genom att utnyttja mobilnätets NTP-tidssynkronisering eliminerade TOTP problemet med osynkroniserade knapptryckningar helt.
HOTP (RFC 4226) och dynamisk trunkering på bytenivå
Den grundläggande matematiska definitionen av HOTP är anmärkningsvärt koncis:
Parameteruppdelning:
K: Delad symmetrisk hemlig nyckel (vanligtvis en Base32-avkodad binär sekvens på 160 bitar / 20 byte).C: 8-byte (64-bitars) heltal i big-endian-format som fungerar som räknare.HMAC-SHA-1: Nyckelbaserad hashfunktion för meddelandeautentisering som producerar en 20-byte (160-bitars) kryptografisk digest.
🔍 Hur dynamisk trunkering (DT) konverterar 20 byte till 6 decimala siffror:
En HMAC-SHA1-digest innehåller 160 bitar (20 byte). Att extrahera 6 enhetliga decimala siffror kräver en deterministisk, kollisionsresistent urvalsmekanism som definieras i avsnitt 5.3 i RFC 4226:
Antag att den hemliga nyckeln är ASCII "12345678901234567890" och räknaren är C = 0. Den resulterande HMAC-SHA1-digesten i hexadecimal form är:
1. Den sista byten är 0x71. 0x71 & 0x0F = 0x01, så Offset = 1.
2. Byte 1 till och med 4 är: 93 cf 18 50. Att nollställa MSB ger 0x13cf1850, vilket i decimal form motsvarar 332 339 280.
3. 332339280 mod 1000000 = 339280. Den resulterande 6-siffriga OTP-koden är 339280!
Utvecklingen till TOTP (RFC 6238): Tidsstegens mekanik
HOTP krävde att räknaren på klienten och servern hölls i fas. På mjukvaruenheter ledde manuella knapptryckningar eller inmatningsförsök till ständiga synkroniseringsfel.
RFC 6238 ersatte räknaren C med ett diskret tidssteg T som härleds direkt från Unix-epokens klocka:
- CurrentUnixTime: Antal sekunder som förflutit sedan 1970-01-01 00:00:00 UTC.
- T0: Referenspunkt för epokinitiering (standardvärde 0 i alla moderna system).
- X (Tidsstegsfönster): Standardrekommenderad tidslängd på 30 sekunder.
- Golvfunktionen ⌊ ⌋: För alla tidsstämplar inom samma 30-sekundersfönster förblir T oförändrat. Till exempel utvärderas alla sekunder mellan 1728211200 och 1728211229 till exakt samma 64-bitars heltal T.
Binär serialisering: När T har beräknats packas det till en 8-byte big-endian binär bytebuffert (med identisk minnesstruktur som räknaren C i HOTP). Därmed förenklas den enhetliga formeln till:
TOTP(K, Tid) = HOTP(K, T)
Denna matematiska elegans förklarar varför autentiseringsappar rullar över token synkront var 30:e sekund utan att kräva någon tillståndssynkronisering över nätverket.
HS[31] & 0x0F); i SHA-512 (64-byte digest) tas offseten från byte 63 (HS[63] & 0x0F). På 99,9 % av alla kommersiella webbplatser (Google, Microsoft, GitHub, AWS) förblir dock SHA-1 standard på grund av kompatibilitet med äldre mobila klienter.
Omfattande jämförelsematris sida vid sida (HOTP vs. TOTP)
| Dimension | HOTP (RFC 4226) | TOTP (RFC 6238) |
|---|---|---|
| Indatavariabel | Händelseräknare C (monotont ökande) | Tidssteg T (30-sekunders Unix-epokfönster) |
| Token-livslängd | Obegränsad (giltig tills den förbrukas vid nästa inloggning) | Strikt 30 sekunder (ogiltigförklaras automatiskt) |
| Serverarkitektur | Tillståndsbevarande (kräver atomära databasskrivningar vid varje inloggning) | Tillståndslös (oberoende NTP-tidskontroll) |
| Risk för replay-attacker | Måttlig (avlyssnad token förblir giltig tills den används) | Minimal (begränsad till resterande sekunder i aktuellt fönster) |
| Primärt felläge | Räknardesynkronisering (oavsiktliga knapptryckningar) | Klockdrift (tidsavvikelse på klientens telefon) |
| Hashfunktioner som stöds | Endast HMAC-SHA-1 | HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512 |
| Branschadoption | Äldre bankdosor, specialiserade fysiska grindar | 99,9 % av alla moderna webbautentiserare |
Desynkronisering kontra klockdrift: Tekniska lösningar
I distribuerade produktionsmiljöer uppstår oundvikligen avvikelser mellan klient och server. Kryptografer utvecklade explicita kompensationsfönster för att upprätthålla tillförlitligheten:
Om en användare trycker på sin token-knapp 5 gånger utan att skicka in koden når klientens räknare C+5 medan servern stannar på C.
RFC 4226 specificerar att servern vid autentisering beräknar ett framåtblickande fönster över [C+1, C+s] (vanligtvis s=20). Om en träff identifieras hoppar servern framåt och synkroniserar räknare C omedelbart.
På grund av nätverkslatens eller klockavvikelse på klientens enhet (t.ex. en mobilklocka som går 10 sekunder efter) kan token anlända i angränsande tidssteg.
Produktionsservrar utvärderar en array med 3 tidsfönster: [T-1, T, T+1], vilket i praktiken ger ett acceptansfönster på 90 sekunder.
När en server kontrollerar om den inskickade koden stämmer överens med den beräknade koden avbryts enkla stränglikhetskontroller (som userOtp === serverOtp) vid det första tecknet som inte matchar. En angripare som mäter mikroskopiska nätverkssvarstider kan därmed återskapa siffrorna iterativt. Företagsinfrastrukturer implementerar konstanttidsjämförelser (t.ex. crypto.timingSafeEqual i Node.js) för att omintetgöra sådana tidsanalyser.
Varför TOTP vann det moderna internet
Den avgörande segern för TOTP över HOTP på webben drevs av tre arkitektoniska fördelar:
I distribuerade mikrotjänster i flera regioner kan vilken serverinstans som helst med en NTP-synkroniserad klocka validera TOTP-koder utan att fråga eller låsa en centraliserad databaspost.
Smartphones kalibrerar ständigt sina systemklockor via mobilmaster och GPS, vilket eliminerar klockdrift helt utan behov av fysiskt underhåll.
HOTP-koder förblir giltiga på obestämd tid tills de förbrukas. TOTP-koder upphör att gälla inom 30 sekunder, vilket automatiskt neutraliserar komprometterade loggar och nätverksavlyssningar.
Upplev TOTP-beräkningar i realtid i 2FA-Tool
Se hur din Base32-hemliga sträng omvandlas till dynamiska 6-siffriga koder via HMAC-SHA1 dynamisk trunkering. 100 % offline i din webbläsare.
📚 Relaterade säkerhetsguider
Hur du flyttar 2FA-konton mellan smartphones med hjälp av offline-QR-koder och Cloud Sync.
Efterlevnadskrav, spara återställningskoder, SSH-nycklar och nödåterställning.
Hur du återställer åtkomst till Google, Microsoft, Steam, Binance, Apple och Discord.