TOTP

TOTP (Time-based One-Time Password) ist der Algorithmus hinter Google Authenticator, Authy, der TOTP-Funktion von 1Password und den meisten softwarebasierten 2FA-Verfahren. Definiert in RFC 6238 (2011).

So funktioniert es: Bei der Registrierung tauschen Server und Authenticator-App ein gemeinsames Geheimnis aus (typischerweise ein 160-Bit-Wert, codiert als Base32-String oder QR-Code). Um das aktuelle OTP zu erzeugen, gehen beide Seiten so vor:

1. Die aktuelle Unix-Zeit nehmen, durch die Periode (Standard 30 Sekunden) teilen, abrunden.
2. HMAC-SHA1 dieses Zählers mit dem gemeinsamen Geheimnis berechnen.
3. Auf 6 Ziffern kürzen.

Beide Seiten erzeugen denselben Code, ohne zu kommunizieren. Das 30-Sekunden-Fenster plus eine Toleranz von ±1 Fenster fängt Uhrenabweichungen ab. Das gemeinsame Geheimnis verlässt das Gerät nach der Registrierung nie.

TOTP ist enorm besser als SMS-OTP (keine SIM-Swap-Angriffsfläche), schlägt Phishing aber nicht für sich allein — ein Angreifer, der den aktuellen Code abfischt, kann ihn innerhalb des Fensters wiederverwenden. WebAuthn / Passkeys sind die Antwort der nächsten Generation.

Das Bereitstellungsformat für das gemeinsame Geheimnis: Die von Google Authenticator, GitHub, AWS IAM und anderen angezeigten QR-Codes kodieren eine otpauth://totp/Issuer:label?secret=BASE32SECRET&algorithm=SHA1&digits=6&period=30-URI. Das Schema ist eine Google-Konvention von 2011, keine formale IETF-Spezifikation, doch jede große Authenticator-App unterstützt es. Manche Dienste (Microsoft, Steam) erweitern die Ziffern auf 7–8 oder verkürzen die Periode auf 15 Sekunden für höhere Entropie auf Kosten eines engeren Fensters. Lesen Sie den QR-Code einmal mit einer generischen QR-Reader-App, um das Geheimnis zu erfassen, und sichern Sie es dann offline — den Authenticator ohne diese Sicherung zu verlieren, bedeutet, die Konto-Wiederherstellung durchlaufen zu müssen.

SHA-1 in einer Spezifikation von 2026 — ist das sicher? Ja, in diesem Kontext. Die Verwendung von HMAC-SHA1 durch TOTP ist nicht anfällig für die SHA-1-Kollisionsangriffe, die den Hash für TLS-Zertifikate ausmusterten; HMAC hängt von der Urbildresistenz von SHA-1 ab, die intakt bleibt. RFC 6238 erlaubt auch SHA-256 und SHA-512, doch praktisch jede Authenticator-App nutzt standardmäßig SHA-1 für die anbieterübergreifende Kompatibilität. Gibt die Provisionierungs-URI algorithm=SHA256 an, müssen Prüfer und Authenticator es beide unterstützen — viele ältere Apps gehen stillschweigend kaputt. Verwandt: OTP, SHA-256, JWT.

Durchgerechnetes Beispiel: einen Code ableiten

Gemeinsames Geheimnis (Base32) JBSWY3DPEHPK3PXP. Angenommen, die aktuelle Unix-Zeit ist 1700000000. Zähler = floor(1700000000 / 30) = 56666666. Packen Sie den Zähler als 8-Byte-Big-Endian-Ganzzahl, berechnen Sie HMAC-SHA1(Geheimnis, Zähler), was einen 20-Byte-Digest ergibt, nehmen Sie das niederwertige Nibble des letzten Bytes als Offset o, lesen Sie 4 Byte ab o, maskieren Sie das oberste Bit und rechnen Sie modulo 10⁶. Das Ergebnis ist ein 6-stelliger Code wie 359152. Bei t = 1700000030 erhöht sich der Zähler um 1 und der Code wechselt. Zwölf Sekunden Uhrenabweichung zwischen Server und Telefon sind harmlos; sechzig Sekunden lassen die Prüfung in der Regel scheitern, sofern der Server das Toleranzfenster nicht erweitert.

Wann TOTP die richtige Wahl ist

TOTP ist als zweiter Faktor überall sinnvoll, wo ein Angreifer, der bereits das Passwort hat, dennoch blockiert werden soll: Bank-Logins, Code-Hosting, Cloud-Konsolen, E-Mail. Es ersetzt kein Passwort (das Geheimnis ist symmetrisch — eine Server-Kompromittierung legt den Seed jedes Nutzers offen) und es stoppt keine Echtzeit-Phishing-Kits wie evilginx, die den Login-Ablauf proxen. Für phishingresistente Authentifizierung bevorzugen Sie WebAuthn / Passkeys, die das Anmeldedatenobjekt kryptografisch an die legitime Origin binden. Quelle: NIST SP 800-63B — Digital Identity Guidelines (Authentication), das TOTP als „etwas, das man besitzt“ vom AAL2-Niveau einstuft, äquivalent zu einem gemerkten Geheimnis.