Abgelehnte MFA-Anfrage im VPN: Was der Client tun sollte

Eine abgelehnte MFA-Abfrage sieht aus wie ein Netzwerkproblem und ist keines. Der Server fragte nach einem zweiten Faktor, der Faktor kam negativ zurück oder traf nie ein, und die Sitzung wurde abgelehnt, bevor überhaupt ein Tunnel existierte. Was danach passiert, ist eine Frage des Client-Verhaltens: den Fehler sichtbar machen und den Nutzer einen sauberen Versuch beginnen lassen oder auf Arten wiederholen, die weitere Abfragen erzeugen und irgendwann den Kontoschutz auslösen. Der zweite Weg ist der, auf dem aus einem falsch getippten Code ein gesperrtes Konto wird.

Prüfen, welche Anfrage fehlgeschlagen ist

Beginnen Sie damit, festzustellen, welche Anfrage fehlgeschlagen ist. Eine Push-Benachrichtigung, ein TOTP-Code, eine FIDO-Assertion und ein SAML-Ablauf scheitern jeweils anders, und der Client weiß normalerweise, wonach er gefragt hat. Eine Ablehnung, eine abgelaufene Challenge und ein Zustellfehler, der das Gerät nie erreichte, enden alle in derselben allgemeinen Fehlermeldung, daher ist der eigene Zustand des Clients oft der einzige Ort, an dem der Unterschied überlebt.

Dieser Zustand lohnt sich, präzise zu protokollieren. Erfassen Sie die Challenge-Kennung oder Transaktionsreferenz, den Faktortyp, den Zeitstempel und das Ergebnis, aber niemals den Code oder die Assertion. Die Challenge-Kennung ist das, was einen Administrator in die Lage versetzt, das Ereignis auf der Seite des Identitätsanbieters zu finden; ohne sie beginnt das Support-Gespräch mit „irgendwann in der letzten Stunde“ und endet meist dort. Behandeln Sie sie als diagnostische Metadaten, nicht als Geheimnis.

Einmal gezielt wiederholen, mit einer neuen Challenge

Ein erneuter Versuch sollte ein neuer Versuch mit einer neuen Challenge sein, keine Wiederholung der alten. Wenn der Client die vorherige Challenge wiederverwendet, lehnt der Identitätsanbieter sie entweder als veraltet ab oder, schlimmer, akzeptiert eine Freigabe, die für den früheren Versuch gedacht war. Fordern Sie eine frische Challenge an, zeigen Sie sie an und lassen Sie den Nutzer auf der handeln, die gerade auf dem Bildschirm ist.

Zwei Versuche mit einer kurzen Pause dazwischen sind ein vernünftiger Standard; eine unbegrenzte Schleife ist es nicht. Scheitert der zweite Versuch genauso, hören Sie auf und melden Sie es, statt weiterzumachen.

Was der Client nicht tun darf

Der Client darf mehrere Dinge nicht tun, die hilfreich wirken und es nicht sind. Er darf nicht so lange Push-Benachrichtigungen nachsenden, bis jemand auf Zustimmen tippt, denn das trainiert Nutzer, Abfragen zu bestätigen, die sie nicht ausgelöst haben, und genau auf dieses Verhalten setzen Phishing-Kits. Er darf nicht auf einen schwächeren Faktor zurückfallen, weil der starke versagt hat, und er darf nicht die Server-Identitätsprüfung abschalten, um an einer Zertifikatsbeschwerde vorbeizukommen, die gleichzeitig auftrat. Jede dieser drei Abkürzungen macht aus einem Authentifizierungsfehler einen Sicherheitsvorfall.

Er darf den Fehler auch nicht stillschweigend verschlucken. Ein Client, der die Verbindung schließt und einen Spinner zeigt, lässt den Nutzer ohne jede Ahnung, ob er wiederholen, warten oder den Support anrufen soll. Zeigen Sie den Fehler mit Faktortyp und einem kurzen Code, halten Sie die Meldung frei von Geheimnissen und machen Sie die Wiederholung ausdrücklich statt automatisch.

Wurde die Anfrage nicht von der Person an der Tastatur ausgelöst, ist die richtige Handlung, sie abgelehnt zu lassen und sie über den verifizierten Support-Weg zu melden. Eine Abfrage zu bestätigen, um das Rauschen zu beenden, ist das Fehlermuster, nicht die Lösung.

Was für den Support zu erfassen ist

Für den Support ist der nützliche Datensatz klein. Die ungefähre Zeit mit Zeitzone, das Konto, der Client und die Version, der Faktortyp und der nicht geheime Status jedes Versuchs: angefragt, abgelehnt, abgelaufen, bestätigt, aber durch Richtlinie abgelehnt.

Behalten Sie auch die Uhren von Client und Server im Blick. TOTP ist eine Zeitfensterprüfung, ein Gerät mit abweichender Uhr erzeugt also gültig aussehende Codes, die jedes Mal scheitern, und ein Client, der einen ungültigen Code meldet, ohne die Abweichung zu erwähnen, schickt Leute dazu, Anmeldedaten zurückzusetzen, die nie falsch waren. Ein Nutzer, dessen Login wiederholt scheitert, sollte die unterstützte Client-Version, den Registrierungsstatus und den dokumentierten Wiederherstellungsablauf prüfen, bevor er weitere Abfragen erzeugt.

Der Wiederherstellungsweg verdient dieselbe Sorgfalt wie der Login-Weg. Ein Ablauf für verlorene Geräte existiert genau deshalb, damit eine Ablehnung nicht zur Erlaubnis wird, die Authentifizierung zu umgehen, und ein Client sollte auf den dokumentierten Prozess der Organisation verlinken, statt einen eigenen zu erfinden.

Die Regel, gegen die man baut, lautet: Eine Ablehnung ist ein Ergebnis, kein Hindernis. Melden Sie sie einmal, klar, mit genug Kontext zum Handeln, und lassen Sie den nächsten Versuch ein neuer sein. Die CISA-Empfehlungen zu phishing-resistenter MFA erklären, warum das Muster „fragen, bis bestätigt wird“ von vornherein gefährlich ist, und sie sind die Referenz, die man zitieren sollte, wenn jemand eine Wiederholungsschleife vorschlägt. Alles, was der Client nach einer Ablehnung ergänzt, sollte die nächste Entscheidung für einen Menschen leichter machen und ihm die Entscheidung nicht abnehmen.