Wie erzeugt eine TOTP-Authenticator-App diese 6-stelligen Codes?
Kurzantwort
TOTP (Time-based One-Time Password) kombiniert ein bei der Einrichtung festgelegtes gemeinsames Geheimnis mit der aktuellen, in feste Fenster (meist 30 Sekunden) unterteilten Zeit. Es führt HMAC über den Zeitschritt-Zähler mit dem Geheimnis aus und kürzt das Ergebnis dann auf einen 6-stelligen Code. Sowohl App als auch Server halten dasselbe Geheimnis und dieselbe Uhr, sodass sie unabhängig denselben Code berechnen – ohne Netzwerkaufruf. Der Code wechselt mit jedem Fenster.
Diese Frage prüft, ob du verstehst, dass Authenticator-Codes berechnet, nicht geliefert werden – es gibt keine Nachricht in Transit, die abgefangen werden könnte, was TOTP stärker als SMS macht.
Die Einrichtung
Bei der Registrierung erzeugt der Server ein zufälliges gemeinsames Geheimnis und zeigt es deiner App, meist als QR-Code (die otpauth://-URI). Sowohl der Server als auch deine Authenticator-App halten nun dasselbe Geheimnis. Nichts von diesem Geheimnis reist je wieder über das Netz.
Einen Code erzeugen
TOTP ist direkt auf HMAC aufgebaut (es ist HOTP mit einem zeitbasierten Zähler). Die aktuelle Unix-Zeit wird durch eine Schrittgröße geteilt – typischerweise 30 Sekunden –, um einen Zählerwert zu erzeugen. Die App berechnet HMAC(secret, time_step) und wendet dann eine definierte dynamische Kürzung an, um diesen Digest auf eine 6-stellige Zahl zu reduzieren. Da die Eingabe das Zeitfenster ist, ändert sich der Code alle 30 Sekunden. Der Server, der dasselbe Geheimnis hält und dieselbe Uhr liest, berechnet den identischen Code und vergleicht. Kein Roundtrip, kein SMS, keine E-Mail – das beseitigt die SIM-Swap- und Abfangrisiken, die SMS-OTP plagen.
Umgang mit Uhrendrift
Telefone und Server haben keine perfekt synchronisierten Uhren, daher akzeptieren Server typischerweise den Code der benachbarten Zeitfenster (einen Schritt davor/danach), um kleine Drift zu tolerieren, und balancieren so Benutzerfreundlichkeit gegen das etwas größere Ratefenster.
Die Einschränkung
TOTP ist nicht phishing-resistent. Ein Echtzeit-Phishing-Proxy kann eine gefälschte Anmeldeseite präsentieren, sowohl das Passwort als auch den aktuellen 6-stelligen Code abfangen und sie innerhalb des 30-Sekunden-Fensters auf der echten Seite wiederholen. Deshalb sind FIDO2/Passkeys – die die Anmeldeinformation kryptografisch an die legitime Origin binden – der Goldstandard. TOTP bleibt weit besser als SMS und ein solider zweiter Faktor für die meisten Apps.
Worauf Interviewer achten
Die HMAC-Berechnung aus gemeinsamem Geheimnis plus Zeit, „offline berechnet, nicht übertragen", die 30-Sekunden-Rotation und die Toleranz gegenüber Uhrendrift sowie die Ehrlichkeit, dass TOTP dennoch in Echtzeit gephisht werden kann, während SMS noch schwächer ist.
Wahrscheinliche Anschlussfragen
- Warum kann TOTP dennoch in Echtzeit gephisht werden, und was behebt das?
- Wie gehen Server mit Uhrendrift zwischen App und Server um?
- Warum muss das gemeinsame Geheimnis auf beiden Seiten im Ruhezustand geschützt werden?