TOTP vs. HOTP verständlich erklärt: Unterschiede, Funktionsweise & Sicherheit
Ein tiefgehender technischer Blick auf die beiden Pfeiler moderner Zwei-Faktor-Authentifizierung: Vom ereignisbasierten Zähler zur zustandslosen Zeitfenster-Kryptographie.
HOTP (RFC 4226) generiert Einmalkennwörter basierend auf einem persistenten, gemeinsamen Zähler $C$. Jeder Knopfdruck erhöht den Zähler, was bei Diskrepanzen zu Resynchronisationsproblemen führt. TOTP (RFC 6238) ist eine elegante Weiterentwicklung von HOTP: Es ersetzt den fehleranfälligen Zähler durch das globale Zeitintervall $T = \lfloor( ext{Unix-Zeit} - T_0) / X floor$ (typischerweise $X = 30$ Sekunden). Dadurch arbeitet TOTP vollständig zustandslos und skaliert reibungslos über unbegrenzte Server-Cluster.
1 Historische Entwicklung: Von Hardware-Tokens zu offenen Standards
In den 1990er und frühen 2000er Jahren war Zwei-Faktor-Authentifizierung fast ausschließlich Großunternehmen vorbehalten. Proprietäre Hardware-Generatoren wie RSA SecurID dominierten den Markt. Diese proprietären Lösungen brachten gravierende Nachteile mit sich: proprietäre Algorithmen, hohe Lizenzkosten, geschlossene Lieferketten und Vendor-Lock-in.
Die Initiative for Open Authentication (OATH) durchbrach dieses Monopol durch offene, mathematisch transparente Standards:
Einführung des HMAC-basierten Einmalkennwort-Algorithmus. Erstmals konnte jeder Hardware-Hersteller interoperable Tokens fertigen, ohne proprietäre Lizenzen erwerben zu müssen.
Perfektionierung des Algorithmus für Smartphones und Webdienste. Durch die Nutzung der Systemzeit entfiel die serverseitige Zählersynchronisation vollständig.
2 HOTP (RFC 4226): Die Mechanik der dynamischen Trunkierung
HOTP bildet das mathematische Fundament. Die zentrale Formel lautet:
Hierbei ist $K$ der symmetrische Geheimschlüssel und $C$ ein 8-Byte-Zähler in Big-Endian-Notation. Da der Output von HMAC-SHA1 20 Bytes lang ist, muss dieser String in eine für Menschen lesbare Zahl (z. B. 6 Ziffern) umgewandelt werden. Dies geschieht über die Dynamic Truncation:
- Offset-Ermittlung: Das letzte Halbbyte (untere 4 Bits) des 20. Bytes bestimmt den Offset $Offset \in [0, 15]$.
- 4-Byte-Extraktion: Ab dem berechneten Offset werden 4 aufeinanderfolgende Bytes extrahiert.
- Vorzeichenbit löschen: Das höchstwertige Bit (MSB) wird maskiert (
& 0x7FFFFFFF), um plattformübergreifende Vorzeichenfehler zu verhindern. - Modulo-Reduktion: Der resultierende 31-Bit-Integer wird modulo $10^6$ gerechnet und mit führenden Nullen formatiert.
3 TOTP (RFC 6238): Der Zeitschritt-Mechanismus
TOTP nutzt exakt denselben Trunkierungsmechanismus wie HOTP, ersetzt jedoch den Zähler $C$ durch eine Zeitvariable:
Standardmäßig ist $T_0 = 0$ (1. Januar 1970 UTC) und der Zeitschritt $X = 30$ Sekunden. Das bedeutet: Innerhalb eines zusammenhängenden 30-Sekunden-Fensters ist der Eingabewert $T$ für Client und Server absolut identisch. Nach Ablauf der 30 Sekunden ändert sich $T$ inkrementell um 1, wodurch sofort ein völlig neuer Code berechnet wird.
4 Direkte Gegenüberstellung: HOTP vs. TOTP
| Kriterium | HOTP (RFC 4226) | TOTP (RFC 6238) |
|---|---|---|
| Eingabevariable | Ereigniszähler $C$ (Inkrementell) | Unix-Zeitschritt $T$ (30 Sek.) |
| Gültigkeitsdauer | Unbegrenzt bis zur nächsten Nutzung | Strikt 30 Sekunden (vergänglich) |
| Server-Zustand | Zustandsbehaftet (Stateful) | Zustandslos (Stateless) |
| Cloud-Skalierbarkeit | Schwierig (Race Conditions bei Clustern) | Optimal (Keine DB-Locks nötig) |
| Phishing-Resistenz | Niedrig (Code bleibt gültig) | Höher (Verfällt nach wenigen Sekunden) |
5 Zähler-Desynchronisation vs. Zeitverschiebung
Beide Algorithmen müssen mit potenziellen Abweichungen zwischen Authentifikator und Server umgehen, nutzen dafür jedoch völlig unterschiedliche Strategien:
Drückt der Nutzer seinen Token unterwegs 15-mal, ohne sich einzuloggen, hat der Token $C=15$, während der Server noch bei $C=0$ steht. Um dies abzufangen, berechnet der Server bei jedem Login nicht nur $C$, sondern prüft die nächsten $s$ Werte (z. B. $C+1$ bis $C+20$). Überschreitet der Versatz dieses Fenster, ist eine aufwendige manuelle Re-Synchronisation erforderlich.
Bei TOTP können die internen Uhren von Smartphone und Server um wenige Sekunden abweichen. Server prüfen daher standardmäßig das Fenster $T-1$, $T$ und $T+1$ (ein Toleranzfenster von $\pm 30$ Sekunden). Moderne Geräte synchronisieren ihre Uhr automatisch über NTP, wodurch Desynchronisationen in der Praxis nahezu ausgeschlossen sind.
6 Warum sich TOTP im modernen Web durchgesetzt hat
Dass Apps wie Google Authenticator, Bitwarden, 2FAS und Microsoft Authenticator heute fast ausschließlich auf TOTP setzen, hat fundamentale architekturelle Gründe:
- Zustandslose Verifikation: In weltumspannenden Cloud-Infrastrukturen (wie AWS oder Cloudflare) muss bei TOTP kein Zählerstand synchron in eine Datenbank zurückgeschrieben werden. Jeder beliebige Server weltweit kann den Code unabhängig verifizieren.
- Kein Replay-Angriff: Da jeder Code nach spätestens 60 Sekunden verfällt, ist das Angriffsfenster für abgefangene Tokens extrem klein.
- Universelle Smartphone-Kompatibilität: Dank integrierter atomarer Zeitquellen in modernen Mobilfunknetzen ist die lokale Uhrzeit auf jedem Smartphone weltweit auf Millisekunden präzise.
❓ Häufig gestellte Fragen (FAQ)
Gibt es heute noch sinnvolle Einsatzbereiche für HOTP? ▼
Ja. Hardware-Token ohne integrierte Batterie und Echtzeituhr (RTC), wie beispielsweise einfache YubiKey-Slots oder Offline-Banking-Kartenleser, verwenden weiterhin HOTP, da sie keine Zeitstempel messen können.
Beeinflussen Zeitzonen oder Sommerzeit die TOTP-Berechnung? ▼
Nein. Die Unix-Epoche basiert auf den vergangenen Sekunden seit dem 1. Januar 1970 00:00:00 UTC. Zeitzonen und Sommerzeit-Verschiebungen sind reine Anzeigeformate des Betriebssystems und haben keinerlei Einfluss auf den zugrundeliegenden UTC-Zeitstempel.
Spezialisiert auf angewandte Kryptographie, IETF-Standards und Zero-Trust-Architekturen. Wir überprüfen alle Algorithmen gegen offizielle IETF-Testvektoren.