SMS-OTP-Sperrfenster: Doppelte Neuversendungen reduzieren, ohne legitime Nutzer zu blockieren

Das operative Problem: Neuversendungen sind nicht nur eine UX-Funktion

Wenn eine Person mehrfach einen SMS-OTP-Code anfordert, kann das System gleichzeitig gültige Codes erzeugen, die Messaging-Kosten erhöhen, Verwirrung darüber schaffen, welcher Code eingegeben werden soll, und die Angriffsfläche für Missbrauch vergrößern. Es kann auch zu mehr Supportanfragen kommen, wenn Nutzer verspätete Nachrichten erhalten oder ein früherer Code ohne klare Erklärung nicht mehr funktioniert.

Eine starre Unterdrückung jeder wiederholten Anfrage kann jedoch eine legitime Authentifizierung verhindern. Die Verzögerung kann im Netz, beim Messaging-Anbieter, im Endgerät oder in der Konnektivität des Nutzers liegen. Zudem können sich manche Nutzer nicht jederzeit auf Mobilfunkabdeckung verlassen und müssen Zugang zu autorisierten alternativen Authentifizierungsmethoden haben.

Das SMS-OTP-Sperrfenster ist eine operative Kontrolle, die entscheidet, ob eine neue Anfrage akzeptiert, verzögert oder ohne erneuten SMS-Versand behandelt werden soll. Es ersetzt nicht die Sicherheitskontrollen des OTP: Es muss zusammen mit der begrenzten Gültigkeit des Geheimnisses, der einmaligen Akzeptanz, der Begrenzung von Verifizierungsversuchen und der Risikobewertung funktionieren.

• Sicherheitsziel: Missbrauch bei Anfragen und Prüfversuchen begrenzen.
• Operatives Ziel: doppelte Nachrichten und inkonsistente Zustände vermeiden.
• Erlebnisziel: über die Wartezeit informieren, ohne offenzulegen, ob ein Konto oder eine Nummer existiert.
• Barrierefreiheitsziel: alternative Methoden anbieten, wenn SMS nicht nutzbar ist.

Was ein Sperrfenster steuert

Ein Sperrfenster sollte nicht nur die Frage beantworten: „Wie viel Zeit ist seit dem letzten Klick vergangen?“ Es muss eine vollständige Entscheidung steuern: ob eine neue Anfrage erstellt wird, ob eine noch gültige Anfrage wiederverwendet wird, ob der Versand aufgeschoben wird, ob ein ausstehender Versuch abgebrochen wird oder ob der Nutzer zu einer autorisierten Alternative geleitet wird.

Die Entscheidung muss serverseitig deterministisch sein. Die Benutzeroberfläche kann einen Countdown anzeigen, darf aber nicht darüber bestimmen, wann ein Neuversand zulässig ist. Der Server verwaltet den Anfragestatus, bewertet Limits und Risiken, erstellt den Code und entscheidet, welches Geheimnis verifiziert werden kann.

Das Verhalten früherer Codes sollte ausdrücklich definiert sein. Eine häufige Richtlinie besteht darin, vorherige Codes zu invalidieren, sobald ein neuer Code für denselben Zweck und dieselbe Authentifizierungsanfrage ausgestellt wird. Wenn diese Richtlinie gewählt wird, sollte sie dem Nutzer mitgeteilt und atomar umgesetzt werden, damit nicht durch eine Nebenläufigkeitsbedingung zwei Codes gültig bleiben.

• Zulassen: Es gibt keine aktive Anfrage, die unterdrückt werden sollte, und die Limits erlauben den Versand.
• Verzögern: Die Anfrage ist legitim, aber die Abkühlzeit für Neuversand läuft noch.
• Unterdrücken: Es wird eine Duplizierung erkannt, ein gleichwertiger Vorgang läuft bereits oder eine geltende Einschränkung wird überschritten.
• Eskalieren oder Kanal wechseln: Risiko, Barrierefreiheit oder ein bestätigter technischer Fehler rechtfertigen einen autorisierten alternativen Weg.

Die drei wesentlichen Timer trennen

Die Gültigkeit des Codes, die Abkühlzeit für Neuversand und der Ablauf der Anfrage sind unterschiedliche Timer. Werden sie vermischt, entstehen häufig zwei Fehler: Ein akzeptierbarer Code bleibt länger als nötig gültig oder ein legitimer Neuversand wird verweigert, weil Wartezeit und kryptografische Gültigkeit verwechselt werden.

Die Codegültigkeit legt fest, bis wann der Verifizierer das Geheimnis akzeptieren kann. NIST schreibt vor, dass die Out-of-Band-Authentifizierung innerhalb von 10 Minuten abgeschlossen sein muss und dass dasselbe Geheimnis während seiner Gültigkeitsdauer nur einmal akzeptiert werden darf. Eine Implementierung kann eine kürzere Gültigkeit wählen, wenn ihre Risikoanalyse und Nutzererfahrung dies rechtfertigen.

Die Abkühlzeit für Neuversand bestimmt, wie lange die Person warten muss, bevor sie eine weitere SMS anfordern kann. Sie ist eine separate operative Entscheidung: Sie soll wiederholte Klicks und doppelten Datenverkehr reduzieren, ohne als Beweis behandelt zu werden, dass die erste SMS nicht eintreffen wird. Der Ablauf der Anfrage bestimmt, wann die Authentifizierungstransaktion geschlossen wird und ein neuer Ablauf gestartet werden muss.

• Codegültigkeit: steuert die Akzeptanz des Geheimnisses und dessen Widerstand gegen Wiederholung.
• Abkühlzeit für Neuversand: steuert die Häufigkeit neuer Sendungen.
• Ablauf der Anfrage: schließt den Transaktionskontext und verhindert unbegrenzte Zustände.
• Limit für Verifizierungsversuche: steuert fehlgeschlagene Versuche und darf bei Ausstellung eines neuen Codes nicht zurückgesetzt werden.

Zustandsmodell für eine OTP-Anfrage

Modellieren Sie die OTP-Anfrage als interne Transaktion mit einer eindeutigen Kennung. Die Status des Messaging-Anbieters sollten dieser Transaktion zugeordnet werden, dürfen jedoch nicht allein die Gültigkeit des Codes oder das Authentifizierungsergebnis steuern.

Ein Minimalmodell kann die Zustände erstellt, akzeptiert, gesendet, finaler Status gemeldet, verifiziert, abgelaufen und abgebrochen enthalten. Der Status „finaler Status gemeldet“ bedeutet, dass ein terminales Update aus dem Messaging-System eingegangen ist, behauptet aber nicht, dass der Nutzer die SMS gesehen, gelesen oder verwendet hat.

Die Übergänge müssen serverseitig kontrolliert und idempotent sein. Beispielsweise muss eine erfolgreiche Verifizierung die Wiederverwendung des Geheimnisses ausschließen, selbst wenn danach ein verspäteter Zustell-Callback eintrifft. Ebenso darf ein verspätetes oder ungeordnetes externes Update eine abgelaufene, abgebrochene oder bereits verifizierte Anfrage nicht erneut öffnen.

• Erstellt: Der Authentifizierungskontext besteht, aber der Versand wurde noch nicht akzeptiert.
• Akzeptiert: Die internen Prüfungen wurden bestanden und der Versand wurde beschlossen.
• Gesendet: Das System hat die Übergabe an die Messaging-Konnektivität erfasst.
• Finaler Status gemeldet: Ein externer terminaler Status ist eingegangen, dessen Semantik ohne Überinterpretation erhalten bleiben muss.
• Verifiziert: Das gültige Geheimnis wurde zurückgegeben und genau einmal akzeptiert.
• Abgelaufen oder abgebrochen: Die Anfrage kann nicht mehr zu einer erfolgreichen Authentifizierung führen.

Nachweise für Neuversandentscheidungen und Grenzen von DLR

Der stärkste Nachweis für die Authentifizierung ist die erfolgreiche Verifizierung des Geheimnisses innerhalb seiner Gültigkeitsdauer. Ein Transportereignis ersetzt weder die ausdrückliche Reaktion des Nutzers noch beweist es, dass der Code empfangen, gelesen oder im Endgerät eingegeben wurde.

Ordnen Sie die Nachweise für die Entscheidung über einen Neuversand nach ihrer Funktion. Interne Ereignisse zeigen, ob bereits eine aktive Anfrage besteht, ob ein Code weiterhin gültig ist, ob eine Verifizierung stattgefunden hat oder ob Limits erreicht wurden. Die Sendungsantwort zeigt, ob das Messaging-System den Vorgang gemäß seiner Schnittstelle akzeptiert oder abgelehnt hat. DLR können Informationen über gemeldete Zustellstatus liefern, ihre Auslegung hängt jedoch von der in der Messaging-Kette verfügbaren Semantik ab.

Ein als zugestellt gemeldeter DLR darf nicht als unabhängige Bestätigung des physischen Empfangs, des Lesens oder des rechtmäßigen Besitzes des Endgeräts behandelt werden. Auch ein ausstehender DLR beweist keinen Fehler. Die Unterdrückungsrichtlinie sollte sowohl einen sofortigen Neuversand wegen eines fehlenden DLR als auch eine automatische Blockierung wegen eines zugestellten DLR vermeiden.

• Nutzen Sie den internen Status, um die Entscheidungsautorität zu behalten.
• Bewahren Sie die Sendungsantwort und ihre Korrelationskennung auf.
• Speichern Sie den ursprünglichen DLR, seinen Empfangszeitpunkt und seine Zuordnung zur Nachricht.
• Machen Sie aus einem DLR keinen Nachweis für Lesen, Identität, Einwilligung oder erfolgreiche Authentifizierung.
• Validieren Sie das OTP auf dem Server, auch wenn eine Zustellung gemeldet wurde.

Praktische Regeln nach Szenario

Bei der ersten Anfrage validieren und normalisieren Sie das Ziel gemäß dem anwendbaren internationalen Nummerierungsrahmen, erstellen die Transaktion, generieren das kurzlebige Geheimnis und protokollieren das Ereignis, bevor Sie den Versand starten. Das Ergebnis sollte mit Anfrage-, Code- und Nachrichtenkennungen verknüpft werden, ohne das Geheimnis im Klartext zu protokollieren.

Bei einem frühen Neuversand darf nicht automatisch ein weiterer Code erzeugt werden, wenn eine aktive Anfrage besteht und die Abkühlzeit noch nicht abgelaufen ist. Geben Sie eine allgemeine Antwort zurück, die auf die geltende Wartezeit hinweist, und lassen Sie weiterhin die Eingabe des aktuellen Codes zu. Wenn ein Neuversand nach Ablauf der Abkühlzeit erlaubt ist, setzen Sie die gewählte Richtlinie für den vorherigen Code atomar um.

Wenn der Code abgelaufen ist, schließen Sie die vorherige Anfrage und erstellen nur dann eine neue, wenn Limits und Risikosignale dies erlauben. Wenn die Plattform einen technischen Fehler bestätigt, bevor der Versand akzeptiert wurde, kann eine begrenzte Wiederholungs-Ausnahme definiert werden; diese Ausnahme muss nachvollziehbar sein und darf nicht zu einem unbegrenzten Generierungsmechanismus werden.

Bei einem Kanalwechsel sollten Sie nicht voraussetzen, dass SMS für alle Fälle geeignet ist. Die Nutzung des PSTN für Out-of-Band-Authentifizierung birgt Risiken, die bewertet werden müssen. Berücksichtigen Sie verfügbare Risikosignale wie Gerätewechsel, SIM-Wechsel oder Rufnummernportierung und leiten Sie zu einem autorisierten alternativen Authenticator weiter, wenn die Richtlinie dies erfordert.

• Erste Anfrage: Kontext erstellen, protokollieren, senden und Timer aktivieren.
• Neuversand während der Abkühlzeit: den gültigen Code beibehalten und die Wartezeit anzeigen.
• Abgelaufener Code: den vorherigen Kontext schließen, bevor ein neuer Code ausgestellt wird.
• Bestätigter technischer Fehler: eine begrenzte, idempotente und prüfbare Ausnahme anwenden.
• Kanalwechsel: den Risikokontext bewahren und Verifizierungskontrollen nicht abschwächen.

Ausstehende, abgelehnte oder zugestellte DLR: vorsichtige Behandlung

Ein ausstehender DLR zeigt an, dass für diesen Vorgang noch kein terminales Update verfügbar ist. Das ist kein ausreichender Grund, sofort eine weitere SMS zu versenden. Halten Sie die Abkühlzeit ein und ermöglichen Sie die Codeeingabe, solange der Code gültig ist.

Eine gemeldete Ablehnung oder ein Fehler kann eine kontrollierte Wiederholungsrichtlinie rechtfertigen, wenn bestätigt ist, dass der Versand nicht akzeptiert wurde oder gemäß den definierten internen Kriterien nicht fortgeschritten ist. Dennoch muss die Wiederholung Limits und einem Idempotenzschlüssel unterliegen, damit Netzwerkwiederholungen nicht mehrere Nachrichten erzeugen.

Wenn eine Zustellung gemeldet wird, behalten Sie die Regel der Nichtgleichsetzung bei: Das System kann diesen Status für operative Analysen erfassen, darf aber weder jede Alternative blockieren noch daraus schließen, dass der Nutzer bereits über den Code verfügt. Die Authentifizierung ist erst abgeschlossen, wenn der Verifizierer das von der Person zurückgegebene gültige Geheimnis akzeptiert.

• Ausstehend: warten, die Anfrage beibehalten und keinen Fehler ableiten.
• Abgelehnt: die technische Bedeutung des Ereignisses prüfen, bevor erneut versucht wird.
• Zugestellt: als Transportsignal erfassen, nicht als Lesen oder Authentifizierung.
• Ungeordnet: das Ereignis zur Diagnose aufbewahren, ohne den internen Status zurückzusetzen.
• Doppelt: den Callback idempotent akzeptieren und wiederholte Auswirkungen vermeiden.

Missbrauchskontrollen ohne Blockierung legitimer Nutzer

Die Unterdrückung von Neuversendungen sollte mit Anfragelimits und Verifizierungslimits kombiniert werden. Kurze OTP erfordern eine Begrenzung fehlgeschlagener Prüfversuche, um Online-Erraten zu verringern. Die Ausstellung eines neuen Codes darf diesen Fehlversuchszähler nicht zurücksetzen.

Stützen Sie die Kontrolle nicht allein auf eine IP-Adresse. OWASP empfiehlt, Zähler für Fehlversuche dem Konto zuzuordnen und IP, Gerät, Standort, Zeit und Verhalten als ergänzende Signale zu nutzen. Bei OTP-Anfragen können Zielnummer, Konto, Sitzung und Gerät unterschiedlichen Kontext liefern; keines davon darf für sich allein als Identitätsnachweis gelten.

Setzen Sie abgestufte Maßnahmen anstelle einer einzigen binären Antwort ein. NIST berücksichtigt zunehmende Wartezeiten, Bot-Erkennung und adaptive Bewertung als Techniken, die die Begrenzung ergänzen können. Prüfen Sie falsch positive Ergebnisse: Reisen, gemeinsam genutzte Netzwerke, neue Geräte, eingeschränkte Abdeckung und Anforderungen an die Barrierefreiheit können legitimes Verhalten erklären.

• Limits pro Konto: schützen den zugehörigen Authentifizierungsablauf.
• Limits pro Nummer: reduzieren den Versanddruck auf ein bestimmtes Ziel.
• Limits pro Sitzung und Gerät: helfen, automatisierte Wiederholungen im selben Kontext zu erkennen.
• IP und andere Signale: liefern Kontext, dürfen aber nicht das einzige Kriterium sein.
• Stufenweise Eskalation: Wartezeit, zusätzliche Prüfung, autorisierte Alternative oder Überprüfung – abhängig vom Risiko.