Warum TOTP-Codes bei einer falschen Geräteuhr scheitern

Einmalcodes können auf Ihrem Telefon völlig korrekt sein und in derselben Sekunde vom Server abgelehnt werden. Beide Seiten berechnen dieselbe Funktion aus einem gemeinsamen Geheimnis und dem aktuellen Zeitschritt, daher erzeugt eine Uneinigkeit über die Zeit eine Uneinigkeit über den Code. Das macht Uhrabweichung zu einem sicherheitsrelevanten Fehler statt zu einem Ärgernis.

Zwei Uhren sind hier wichtig, und die sichtbare zu korrigieren ist der Teil, den die Leute zuerst machen. Die, die meist Aufmerksamkeit braucht, ist die andere.

Der Code ist eine Funktion der Zeit, kein Passwort

TOTP nimmt das gemeinsame Geheimnis und einen aus der aktuellen Zeit abgeleiteten Zähler, schickt beides durch einen Hash mit Schlüssel und kürzt das Ergebnis auf eine kurze Dezimalzeichenfolge, wie in RFC 6238. Der Zähler rückt bei jedem Zeitschritt vor, üblicherweise dreißig Sekunden, sodass dasselbe Geheimnis einen neuen Wert erzeugt, wenn der Schritt wechselt. Der Prüfer berechnet den erwarteten Wert für den aktuellen Schritt neu und vergleicht, was dasselbe Geheimnis und dieselbe Vorstellung von jetzt erfordert. Ein Passwort bleibt wiederverwendbar, bis es geändert wird, während dieser Wert an einer Grenze abläuft, die der Client nicht sieht.

Deshalb funktioniert ein Code und der nächste scheitert Augenblicke später. Das erklärt auch, warum es ein so unzuverlässiges Vorgehen ist, einen Code aus einer Chatnachricht zu kopieren.

Zwei Uhren müssen übereinstimmen, nicht eine

Registrierungsmaterial ist das erste Gemeinsame, und die Zeit ist das zweite. Stimmt das Geheimnis, während die Uhren stärker abweichen als das tolerierte Fenster, landet jeder erzeugte Wert im falschen Schritt und wird abgelehnt. Stimmen die Uhren überein, während das Geheimnis falsch ist, wird jeder Wert ebenfalls abgelehnt, und beide Fehler sehen auf dem Anmeldebildschirm gleich aus. Sie zu trennen heißt, den Kontoeintrag und die Zeit unabhängig zu prüfen, und zwar in dieser Reihenfolge.

Die Uhr des Prüfers verdient dieselbe Prüfung wie die des Geräts. Ein Server mit defekter Zeitquelle lehnt korrekte Codes aller Nutzer auf einmal ab, und die Meldungen werden einen plötzlichen Ausfall beschreiben statt eine Abweichung. Dieses Muster lohnt sich zu erkennen, denn seine Behebung gehört auf den Server und nicht auf hundert Telefone.

Was es kostet, das Fenster zu vergrößern

Implementierungen können einen Code aus einem benachbarten Schritt akzeptieren, um kleine Unterschiede aufzufangen, und diese Toleranz ist eine Designentscheidung, keine kostenlose Anpassung. Jeder zusätzliche Schritt vervielfacht die Zahl der zu jedem Zeitpunkt gültigen Werte, was genau das ist, was ein ratender Angreifer bevorzugt. Die Wiederholungsregel zählt aus demselben Grund, denn ein zweimal akzeptierter Code ist ein Code, der nutzbringend abgeflossen ist. Ein Administrator, der das Fenster vergrößert, um Beschwerden zu ersticken, tauscht eine echte Eigenschaft gegen eine kosmetische Verbesserung.

Die Uhr zu korrigieren ist die Reparatur, während das Fenster zu vergrößern ein Beruhigungsmittel ist. Das erste beseitigt die Ursache, das zweite verbirgt sie.

Prüfen Sie beide Uhren, bevor Sie es erneut versuchen

Lesen Sie die Zeit auf dem Gerät und auf dem Server ab und vergleichen Sie die Abweichungen statt der angezeigten Ortszeiten. Die Befehle unten zeigen den Synchronisierungszustand und den rohen UTC-Zeitpunkt auf einem Linux-Host oder -Server. Führen Sie sie an beiden Enden aus, bevor Sie irgendeine Authentifizierungseinstellung ändern.

timedatectl
date -u +'%Y-%m-%dT%H:%M:%SZ'
chronyc tracking
timedatectl timesync-status

Eine in Sekunden gemessene Abweichung ist harmlos, eine in Minuten gemessene erklärt eine Ablehnung, und ein System ohne gemeldete Synchronisierungsquelle ist ein Kandidat für beides. Vergleichen Sie die beiden UTC-Zeitstempel direkt, da die Ortszeit eine Zeitzone enthält, die der Algorithmus nie sieht. Sind die Abweichungen klein und scheitern die Codes weiterhin, dann hören Sie auf, Uhren zu justieren, und prüfen Sie stattdessen den Registrierungseintrag. Wiederholte Versuche gegen ein gesperrtes Konto machen den ursprünglichen Fehler schwerer beobachtbar.

Notieren Sie die Ablehnungszeit, die Abweichung und den Fehlertext, und lassen Sie das gemeinsame Geheimnis draußen. Der Support kann mit den ersten drei arbeiten und sollte das vierte nie sehen.