Warum ein gültiger Einmalcode bei der VPN-Anmeldung trotzdem scheitert

Sie öffnen den VPN-Client, geben das Passwort ein, und die sechs Ziffern aus Ihrer Authenticator-App kommen als ungültig zurück — zweimal, dann ein drittes Mal. Am Konto hat sich seit gestern nichts geändert, also ist der Reflex, den Eintrag im Authenticator zu löschen und neu zu scannen — meist die falsche Reparatur. Ein Einmalcode ist kein zweites Passwort: Das Gateway muss ihn in einem bestimmten Schritt, aus einem bestimmten registrierten Eintrag, innerhalb eines bestimmten Zeitfensters abfragen, und die meisten Ablehnungen passieren, bevor die Ziffern verglichen werden. Finden Sie heraus, in welchem Schritt Sie sich befinden, bevor Sie die Registrierung anfassen.

Die Reihenfolge der Abfragen zeigt, in welchem Ablauf Sie sind

Drei Formen decken fast jede VPN-Anmeldung ab, die einen Code enthält. In der zweistufigen Form sendet der Client das Passwort, der Server gibt eine Challenge aus, und der Client fragt erneut. In der kombinierten Form will das Gateway Passwort und Code in einer Übermittlung — manchmal verkettet, manchmal nach einem Trennzeichen, das nur der Betreiber dokumentiert. In der Browser-Form hat der Client gar kein Feld: Der Code geht in eine Webseite, oder eine Push-Bestätigung ersetzt ihn, und der Desktop-Client wartet auf das Ergebnis.

Die falsche Form sieht wie ein schlechter Code aus. Fügen Sie einen frischen Code in ein reines Passwortfeld ein, und der Server liest ihn als Teil des Passworts. Auf Client-Seite machen OpenVPN 2.4 und neuer den Unterschied sichtbar: Ein Server, der mit AUTH_FAILED,CRV1: antwortet, erwartet eine Challenge-Antwort, das Profil braucht also static-challenge oder eine Passwortdatei in SCRV1:-Form. Ein älteres Profil, das nur auth-user-pass trägt, authentifiziert das Passwort und bleibt dann stehen, was im Log wie ein OTP-Fehler aussieht, obwohl kein Code gesendet wurde.

WireGuard verdient es, als Ausnahme genannt zu werden: Es authentifiziert Schlüsselpaare statt Personen, es gibt also kein Feld für einen Code. Wenn ein Anbieter einen bewirbt, ist es etwas außerhalb des Tunnels, das ihn akzeptiert.

Was der Server mit den sechs Ziffern macht

Zeitbasierte Codes folgen RFC 6238, der die ältere zählerbasierte Konstruktion aus RFC 4226 einwickelt: ein HMAC über einen beweglichen Faktor, standardmäßig auf sechs Ziffern gekürzt. Bei TOTP ist der bewegliche Faktor die aktuelle Unix-Zeit geteilt durch einen Schritt, 30 Sekunden, sofern der Betreiber ihn nicht geändert hat. Der Prüfer vergleicht Ihre Ziffern nie mit einem gespeicherten Wert; er berechnet den erwarteten Code aus dem gemeinsamen Seed neu und akzeptiert normalerweise auch die benachbarten Schritte, sodass ein langsamer Roundtrip die Anmeldung nicht scheitern lässt.

Zwei Konsequenzen werden übersehen. Die Zeitzone des Telefons ist irrelevant, weil der Seed nie eine lokale Uhr sieht — nur die Abweichung von der echten UTC zählt, und ein Handgerät, das zwei Minuten vorgeht, scheitert an jedem Code, während es einen sauberen Countdown anzeigt. Und ein Code ist konstruktionsbedingt einmalig: Der Prüfer merkt sich den letzten Zählerwert, den er für diesen Seed akzeptiert hat, sodass dieselben Ziffern, erneut übermittelt, selbst im selben Fenster abgelehnt werden. Ein Client, der nach einem Timeout erneut versucht, kann den gerade gesendeten Code verbrennen.

Zählerbasierte Token verschieben ihren Zähler bei jedem Tastendruck, geraten also aus dem Takt, nachdem Codes erzeugt, aber nie übermittelt wurden; die übliche Reparatur ist ein Resynchronisierungsfenster, das einige Werte voraus akzeptiert. Wenn der Betreiber HOTP registriert hat und Ihre App TOTP anzeigt, ist jeder Wert auf eine Weise falsch, die wie ein Uhrproblem aussieht. Die Provisioning-URI hinter dem QR-Code nennt Typ, Ziffern, Periode und Hash.

Fehler, die wie ein falscher Code aussehen

Der registrierte Eintrag ist der häufigste Verursacher. Authenticator-Apps beschriften Einträge nach Aussteller und Konto, sodass jeder mit zwei Identitäten auf demselben VPN am Ende zwei Einträge haben kann, deren Beschriftungen sich um ein Zeichen unterscheiden. Ein Code gilt für den Seed, der ihn erzeugt hat, und für nichts anderes. Vergleichen Sie die Beschriftung auf dem Telefon mit dem Benutzernamen, den der Server führt, nicht mit dem, von dem Sie glauben, ihn eingegeben zu haben.

Zweitens ein nicht passender Parametersatz. Ein Seed, der mit acht Ziffern, einer Periode von 60 Sekunden oder SHA-256 registriert wurde, liefert Codes, die ein Prüfer ablehnt, der sechs Ziffern, 30 Sekunden und SHA-1 erwartet, und beim Client ist das nicht von einem falschen Code zu unterscheiden. Es tritt nach Migrationen auf, bei denen der Eintrag aus einem Foto des QR-Codes neu hinzugefügt oder der Token-Datensatz mit Standardwerten neu aufgebaut wurde.

Drittens geht es nicht um den Code. Gateways liefern für ein falsches Passwort, einen abgelaufenen Code und ein deaktiviertes Konto absichtlich eine einzige allgemeine Authentifizierungsfehlermeldung, damit niemand prüfen kann, welcher Faktor versagt hat. Lesen Sie das Gateway- oder RADIUS-Log statt des Client-Banners: Eine nie ausgegebene Challenge, eine Zugriffsablehnung ohne OTP-Attribut und eine Richtlinienablehnung sehen auf dem Bildschirm gleich aus und führen zu unterschiedlichen nächsten Schritten.

Eine kurze Reihenfolge, die es eingrenzt

Beginnen Sie mit der billigsten Prüfung und hören Sie beim ersten Schritt auf, der nicht hält.

1. Warten Sie auf einen frischen Code, übermitteln Sie ihn einmal und notieren Sie, ob die Challenge vor oder nach der Annahme des Passworts erscheint.
2. Vergleichen Sie die Beschriftung im Authenticator mit dem Benutzernamen, den der Server speichert.
3. Bestätigen Sie, dass das Profil überhaupt eine Challenge beantworten kann, wie im CRV1-Fall oben.
4. Vergleichen Sie die Geräteuhr mit einer bekannten Zeitquelle; eine Abweichung von mehr als einigen Dutzend Sekunden bricht TOTP schon für sich.
5. Fragen Sie den Betreiber, ob das Token TOTP oder HOTP ist und welche Ziffern, Periode und welcher Hash registriert wurden.

Zwei Regeln verhindern, dass dies alles schlimmer macht. Versuchen Sie nicht viele Male: Viele Gateways zählen Fehler pro Konto und sperren es entweder oder beginnen, Antworten zu verzögern, sodass ein Schwall eine kleine Fehlkonfiguration in ein Support-Ticket verwandelt. Und registrieren Sie das Token nicht als Diagnose neu, denn das macht den alten Seed ungültig; wenn der eigentliche Fehler eine Challenge war, die der Client nie gesendet hat, haben Sie jetzt zwei Änderungen zu erklären statt einer.

Halten Sie Seed und Wiederherstellungscodes aus dem Spiel

Die sechs Ziffern und das Geheimnis dahinter sind nicht austauschbar. Ein Provisioning-QR-Code oder ein Base32-Seed erzeugt jeden künftigen Code für das Konto, gehört also in dieselbe Kategorie wie das Passwort: nicht in einen Screenshot, nicht in einen Ticket-Kommentar, nicht in einen Chat mit jemandem, der Sie zuerst kontaktiert hat. Wiederherstellungscodes sind ein separater Mechanismus — einmalig, überspringen oft die Codeabfrage ganz, und wer einen zum Testen des Kontos ausgibt, entfernt einen Rückfallweg, den er später brauchen könnte.

Ein Code macht auch keine Anmeldeseite vertrauenswürdig: Eine OTP-Abfrage auf einer ähnlich aussehenden Domain sammelt einen gültigen Code ein und spielt ihn im Fenster erneut ab, und das Zertifikat ist weiterhin das, was Ihnen sagt, wo Sie tippen.

Wenn die Reihenfolge bei einem Profil landet, das keine Challenge beantworten kann, reparieren Sie das Profil und testen Sie mit einem frischen Code erneut. Wenn sie bei nicht passenden Registrierungsparametern landet, lassen Sie den Betreiber den Token-Datensatz lesen, bevor irgendjemand etwas scannt. Wenn sie bei einer Sperre landet, warten Sie sie ab, statt den Client zu wechseln — der Kontostatus ist die Blockade, nicht die App.