Deine Authenticator-App und die Website sprechen bei der Anmeldung nie miteinander und kommen trotzdem auf dieselben sechs Ziffern. Sie sind sich einfach über die Uhrzeit einig.
Kurz gesagt
TOTP (Time-Based One-Time Password) ist ein Verfahren, das aus einem gemeinsamen Geheimnis und der aktuellen Uhrzeit einen kurzen Code macht, standardmäßig 30 Sekunden gültig [1]. Es ist die zeitbasierte Form von HOTP, das stattdessen einen Zähler nutzt [1][2]. Authenticator-Apps verwenden es als zweiten Faktor: App und Server berechnen den Code jeweils selbst und vergleichen [4][5]. Unsere Einschätzung: TOTP ist ein guter zweiter Faktor, aber eine gefälschte Login-Seite kann den Code trotzdem abgreifen, deshalb sind Passkeys die stärkere Wahl, wo es sie gibt [4].
So funktioniert’s
- Das gemeinsame Geheimnis. Aktivierst du TOTP, zeigt die Seite einen QR-Code mit dem Geheimnis. Meist ist das ein URI der Form
otpauth://totp/Label?secret=…&issuer=…. Das Geheimnis ist Base32-kodiert, die optionalen Parameter haben Standardwerte: SHA1, 6 Ziffern, 30 Sekunden Periode [3]. Behandle dieses Geheimnis wie ein Passwort. - Die Berechnung. TOTP ist definiert als HOTP(K, T), wobei T die Zeitschritte seit der Unix-Epoche zählt: T = (aktuelle Unix-Zeit − T0) / X, mit den Standardwerten X = 30 Sekunden und T0 = 0 [1]. HOTP bildet HMAC-SHA-1 über Geheimnis und Zähler und kürzt das Ergebnis auf eine kurze Zahl mit mindestens 6 Stellen [2]. TOTP darf auch HMAC-SHA-256 oder HMAC-SHA-512 nutzen [1].
- Die Prüfung. Der Server berechnet den Code für denselben Zeitschritt und vergleicht. Weil Netzverzögerung einen Code in den nächsten Schritt schieben kann, sollte ein Server ein kleines Fenster zulassen, und RFC 6238 empfiehlt höchstens einen Zeitschritt Verzögerung [1]. Die Uhr deines Geräts muss deshalb nah an der echten Zeit liegen.
- Warum das Fenster klein ist. Ein größeres Fenster gibt einem Angreifer mehr Zeit. OWASPs Tabelle nimmt 10 Versuche pro Sekunde ohne Begrenzung an: rund 58 % Erfolg nach 24 Stunden bei einem gültigen Code und 92 % bei dreien [5]. Server brauchen Versuchsgrenzen, und OWASP verlangt strikte [4].
- Wo TOTP schwach ist. Das Geheimnis liegt auf dem Server und auf deinem Gerät. OWASP nennt kompromittierte Handys, unsicher gespeicherte Sicherungs-Seeds und den Ausschluss bei verlorenem Handy. Auch Phishing steht auf der Liste, obwohl die Codes kurzlebig sind [4]. Angreifer nutzen Reverse-Proxy-Werkzeuge, die deinen Code in Echtzeit weiterreichen, und phishing-resistente Authenticatoren binden die Anmeldung an den echten Ursprung [4].
Ein Praxisbeispiel
Das Beispiel aus dem RFC selbst: Mit T0 = 0 und X = 30 ist T bei Unix-Zeit 59 Sekunden gleich 1 und bei 60 Sekunden gleich 2, der Code wechselt also genau in dieser Sekunde [1]. Ein Einrichtungslink aus Googles Doku zum Key-URI-Format sieht so aus [3]:
otpauth://totp/Example:alice@google.com?secret=JBSWY3DPEHPK3PXP&issuer=ExampleWer dieses Geheimnis sieht, kann deine Codes erzeugen, ein echtes gehört deshalb nie in einen Chat, einen Screenshot oder ein Repo. Das Key-URI-Format ist eine De-facto-Konvention aus Googles Wiki und kein RFC, auch wenn ein individueller Internet-Draft, erstmals 2024 erschienen, versucht, es zu beschreiben [3][6]. Seine neueste Fassung, -03 vom 24. Aug. 2026, ist weiterhin ein individueller Entwurf ohne formalen Status im Standardisierungsprozess der IETF [6].
Prüfliste
- Wähle einen Passkey oder Hardware-Schlüssel statt TOTP, wenn eine Seite ihn anbietet [4].
- Scanne den QR-Code nur auf der Sicherheitsseite der Website selbst.
- Speichere die Wiederherstellungscodes, wenn du TOTP aktivierst, und bewahre sie offline auf [5].
- Sichere die Geheimnisse oder richte bei der Einrichtung ein zweites Authenticator-Gerät ein, denn ein verlorenes Handy sperrt dich aus [4].
- Halte die Uhr des Geräts mit der Netzzeit synchron.
- Gib nie einen Code auf einer Seite ein, die du über einen Link in einer Nachricht erreicht hast.