Rate Limiting für SMS-OTPs: Limits nach Nutzer, Nummer, IP und Gerät ohne Beeinträchtigung der Authentifizierung

Warum OTP-Rate-Limiting eine operative Richtlinie und nicht nur eine technische Kontrolle ist

SMS-OTP-Rate-Limiting schützt mehrere Werte gleichzeitig: den Authentifizierungsablauf, das Messaging-Budget, die Betriebskapazität und die Erfahrung von Personen, die sich legitim anmelden möchten. Eine zu großzügige Richtlinie kann automatisierte Anfragen erleichtern, den SMS-Kanal des Empfängers überfluten und künstlichen Traffic verursachen. Eine zu restriktive Richtlinie kann legitime Zugriffe verhindern oder zu einem Weg werden, gezielt Konten mit einem Denial-of-Service anzugreifen.

Ziel ist nicht, SMS wahllos zu blockieren. Es geht darum, messbar und überprüfbar zu entscheiden, wann eine Anfrage zugelassen wird, wann Wartezeit oder zusätzliche Reibung eingeführt wird und wann eine risikobehaftete Aktion vorübergehend eingeschränkt wird. Die Kontrolleinheit sollte der geschützten Aktion und dem beobachteten Risiko entsprechen.

• Missbrauch bei Anfragen von Fehlern bei der Codeeingabe trennen.
• Verhindern, dass eine einzelne Signalquelle wie die IP allein über das Ergebnis entscheidet.
• Die Auswirkungen jedes Limits auf Sicherheit, Conversion, erneute Sendungen und Kosten messen.
• Einen autorisierten Wiederherstellungsweg für Personen bereithalten, die den üblichen Ablauf nicht abschließen können.

Was in einem SMS-OTP-Ablauf geschützt werden muss

Ein OTP-Ablauf enthält unterschiedliche Aktionen, die nicht zwingend dieselbe Quote teilen sollten. Mindestens sollten die erste Codeanfrage, die erneute Sendung, die Codevalidierung sowie der Wechsel zu einem alternativen oder Wiederherstellungskanal getrennt behandelt werden. Jede Aktion hat eine andere Missbrauchsfläche.

Die Codevalidierung erfordert besonders sorgfältigen Schutz. Wenn das Authentifizierungsgeheimnis kurz ist, verlangt NIST ein wirksames Limit aufeinanderfolgender fehlgeschlagener Versuche pro Konto und legt fest, dass die Ausgabe eines neuen Codes diesen Zähler nicht zurücksetzen darf. Der Code muss nur einmal verwendbar sein, und der Out-of-Band-Prozess ist nicht mehr gültig, wenn er nicht innerhalb von zehn Minuten abgeschlossen wird.

Die Anfrage oder erneute Sendung darf den Status eines Kontos nicht allein verändern. Eine wiederholte Anfrage kann eine Wartezeit, eine zusätzliche Prüfung oder eine vorübergehende Einschränkung der Aktion rechtfertigen, darf jedoch keine sensiblen Änderungen bewirken, bevor ein gültiges Geheimnis vorgelegt wird.

• Erstanfrage: schützt vor Automatisierung und der Erzeugung von SMS-Traffic.
• Erneute Sendung: verhindert Duplikate, Empfängerermüdung und künstlichen Druck auf den Transportweg.
• Validierung: begrenzt das Erraten von Codes und muss den Fehlerzähler auch bei Ausgabe eines neuen Codes beibehalten.
• Kanalwechsel oder Wiederherstellung: erfordert eigene Regeln und eine angemessene Risikobewertung.

Nach mehreren Entitäten begrenzen, nicht nur nach IP-Adresse

Eine Richtlinie, die ausschließlich auf der IP basiert, reicht nicht aus. Ein Angreifer kann Versuche auf viele Adressen verteilen, während legitime Nutzer denselben Netzwerkausgang teilen können. OWASP empfiehlt, den Fehlerzähler dem Konto zuzuordnen, statt sich ausschließlich auf die IP zu verlassen.

Am sinnvollsten ist die Kombination mehrerer Dimensionen. Das Konto oder die Anmeldeidentität hilft beim Schutz des Authentifizierungsprozesses; die MSISDN steuert das SMS-Ziel; die IP liefert Kontext zur Herkunft; Gerät, Sitzung sowie Kampagne oder Anwendung ermöglichen das Erkennen von Konzentration. Kein Signal sollte für sich allein als endgültiger Beweis interpretiert werden.

Bevor Quoten nach Nummer angewendet werden, sollte das Ziel konsistent nach einem internationalen Nummerierungsschema wie E.164 normalisiert werden. Ohne Normalisierung können unterschiedliche Darstellungen derselben Nummer Zähler aufspalten oder inkonsistente Entscheidungen erzeugen.

• Konto: entscheidend, um aufeinanderfolgende Validierungsfehler zu begrenzen und vor verteilter Brute Force zu schützen.
• Normalisierte MSISDN: nützlich zur Steuerung von Anfragen und erneuten Sendungen an dasselbe Ziel.
• IP: ergänzendes Signal zum Erkennen von Volumen, Automatisierung oder Konzentration, nicht die Identität des Nutzers.
• Gerät: liefert Kontext, muss jedoch verhältnismäßig eingesetzt werden, da Geräte geteilt werden können.
• Sitzung: ermöglicht die Zuordnung von Anfragen und Validierungen zu einem konkreten Ablauf.
• Kampagne oder Anwendung: hilft, Probleme zu isolieren und zu verhindern, dass eine Integration andere beeinträchtigt.

Wie Fenster, Quoten und Abkühlzeiten ausgewählt werden

Es gibt keine universell überprüfbare Quote, die für alle Dienste geeignet ist. Schwellenwerte sollten aus dem Risiko des Anwendungsfalls, der erwarteten Nutzergruppe, der Betrugstoleranz, der Dienstkapazität und den Auswirkungen einer Sperrung legitimer Personen abgeleitet werden. Sie müssen dokumentiert und anhand eigener Daten überprüft werden.

Ein festes Zeitfenster ist leicht zu erklären und zu auditieren, kann jedoch Anfragen nahe seiner Grenzen bündeln. Ein gleitendes Zeitfenster bietet eine kontinuierlichere Sicht auf das jüngste Verhalten, erfordert aber sorgfältigere Implementierung und Beobachtbarkeit. Eine progressive Abkühlzeit reduziert unmittelbare Wiederholungen, ohne von Anfang an ein langes Verbot zu verhängen.

OWASP nennt drei Elemente, die ausdrücklich festgelegt werden sollten: die Anzahl der Fehler, die eine Einschränkung auslöst, den Zeitraum, in dem sie gezählt werden, und die Dauer der Einschränkung. Außerdem beschreibt OWASP exponentielle Sperren, bei denen die Wartezeit kurz beginnt und nach aufeinanderfolgenden Fehlern steigt.

• Verwenden Sie einfache Zeitfenster, wenn operative Erklärbarkeit und Auditierbarkeit Priorität haben.
• Verwenden Sie gleitende Zeitfenster, wenn künstliche Spitzen rund um einen zeitlichen Reset vermieden werden sollen.
• Wenden Sie auf wiederholte Aktionen progressive Abkühlzeiten an, bevor umfangreiche Sperren eingesetzt werden.
• Dokumentieren Sie für jede Regel: Entität, Aktion, Schwellenwert, Zeitfenster, Dauer, autorisierte Ausnahme, verantwortliche Person und Bedingung für die Rücknahme.

Die Trennung von Anfrage, erneuter Sendung und Validierung verhindert widersprüchliche Kontrollen

Die Erstanfrage und erneute Sendung verbrauchen Messaging-Kapazität; die Validierung verbraucht Verifizierungskapazität und ist dem Risiko des Codeerratens ausgesetzt. Ein einziger Zähler für den gesamten Ablauf vermischt Ursachen und erschwert die Untersuchung von Vorfällen.

Eine vorsichtige Implementierung kann einen Challenge-Status pro Sitzung oder Transaktion führen: normalisiertes Ziel, Konto sofern im Ablauf vorhanden, Anfragekennung, Ausgabezeit, Ablaufzeit, Nutzungsstatus, Zähler fehlgeschlagener Validierungen und pseudonymisierte Verweise auf Risikosignale. Das OTP-Geheimnis darf nicht im Klartext protokolliert werden.

Idempotenz ist ebenfalls wichtig. Wenn der Client eine Anfrage wegen einer verlorenen Antwort oder einer Netzwerksituation wiederholt, sollte der Dienst die Wiederholung innerhalb eines kontrollierten Kontexts erkennen können, statt unnötig mehrere Nachrichten zu erzeugen. Diese Entscheidung reduziert Duplikate und macht die Zählung von Anfragen zuverlässiger.

• Setzen Sie Validierungsfehler nicht zurück, wenn ein neuer Code generiert wird.
• Markieren Sie den Code nach einer gültigen Verwendung als verbraucht, um eine Wiederverwendung zu verhindern.
• Machen Sie für Nutzer sichtbar, wann sie einen neuen Versand anfordern können, ohne Kontoinformationen offenzulegen.
• Gestalten Sie technische Wiederholungsversuche idempotent, damit sie nicht mit neuen menschlichen Anfragen verwechselt werden.
• Trennen Sie Versandwarteschlangen von der Autorisierungslogik: Eine akzeptierte Anfrage bestätigt keine Authentifizierung.

Sichere Antworten und progressive Reibung

Die Antwort eines OTP-Endpunkts sollte neutral hinsichtlich Existenz, Status und möglicher Sperrung eines Kontos sein. OWASP empfiehlt konsistente Meldungen und einheitliches Timing, um Enumeration durch Unterschiede bei Inhalt oder Zeit zu verringern.

Wenn ein Risikosignal zunimmt, ist progressive Reibung einer breit angelegten Sperre vorzuziehen. Beispielsweise können eine sichtbare Wartezeit vor einer erneuten Sendung, eine zusätzliche Prüfung gegen Automatisierung oder eine Risikoprüfung angemessene Maßnahmen sein. CAPTCHA kann als Defense-in-Depth dienen und nach einigen Fehlern eingeführt werden, nicht zwingend beim ersten Versuch.

Einschränkungen müssen Missbrauch verhindern, ohne Dritten zu ermöglichen, legitime Nutzer auszusperren. Daher sollte keine umfangreiche Kontosperre allein deshalb erfolgen, weil jemand wiederholt Codes für dieses Ziel angefordert hat.

• Verwenden Sie Meldungen wie: „Wenn der Ablauf gültig ist, erhalten Sie Anweisungen oder können fortfahren, sobald die Wartezeit endet.“
• Zeigen Sie einen Countdown für die erneute Sendung an, der an die Transaktion gebunden ist, nicht Informationen darüber, ob ein Konto existiert.
• Erhöhen Sie die Reibung anhand von Wiederholung, Geschwindigkeit und Signalkonzentration, nicht aufgrund einer einzelnen isolierten Beobachtung.
• Reservieren Sie Einschränkungen mit größerer Auswirkung für bestätigtes Risiko und eine definierte Dauer.
• Bieten Sie eine autorisierte Wiederherstellung an, wenn der übliche Kanal nicht nutzbar ist.

Signale, die eine Überprüfung oder Verschärfung der Kontrollen rechtfertigen

Risikosignale dienen dazu, Überprüfungen zu priorisieren und Kontrollen anzupassen; sie entsprechen nicht allein einer Identität oder einem Betrugsnachweis. OWASP empfiehlt, Daten aus Clients, Geräten, Netzwerken oder externen Diensten als nicht vertrauenswürdig zu behandeln, da sie fehlen, wiederholt, verändert oder gefälscht sein können.

Achten Sie auf Muster von Konzentration und Wiederholung: viele Anfragen für dasselbe Ziel, schnelle Aktivität aus einer Quelle, Folgen erneuter Sendungen ohne Validierung, anhaltende Codefehler oder ungewöhnliches Volumen innerhalb derselben Anwendung. Bei PSTN-Kanälen empfiehlt NIST, vor dem Versand des Geheimnisses Indikatoren wie Gerätewechsel, SIM-Wechsel, Rufnummernportierung oder anderes anomales Verhalten zu berücksichtigen.

Das Gerät erfordert eine besonders vorsichtige Behandlung. Es kann ein nützliches Signal gegen Missbrauch in großem Umfang liefern, doch auch Geräte werden geteilt. Eine Gerätezuordnung darf nicht in eine automatische Zugangssperre für mehrere legitime Nutzer umgewandelt werden.

• Konzentration: Wiederholung bei einem Konto, einer Nummer, einer Sitzung oder einer Anwendung.
• Geschwindigkeit: Taktung, die mit der erwarteten normalen Nutzung des Ablaufs nicht vereinbar ist.
• Fehlermuster: mehrere falsche Validierungen oder Anfragen ohne Abschluss.
• Ziel: ungewöhnliche Änderungen im Muster der Ziele innerhalb einer Anwendung.
• Kontextuelles Risiko: Hinweise auf Gerätewechsel, SIM-Wechsel oder Portierung, als Signale und nicht als Gewissheiten behandelt.
• Signalqualität: unvollständige oder nicht vertrauenswürdige Daten sollten die Entscheidungssicherheit verringern, nicht automatisch zu strengeren Maßnahmen führen.

Was protokolliert werden sollte, ohne mehr Daten als nötig zu speichern

Protokolle ermöglichen es, eine Entscheidung zu erklären, Missbrauch zu untersuchen und Fehlalarme zu erkennen. OWASP empfiehlt, erfolgreiche und fehlgeschlagene Authentifizierungen, Versuche zur Überschreitung von Limits sowie verdächtige Aktivitäten in der Geschäftslogik zu protokollieren und dabei eine konsistente, dokumentierte Taxonomie zu verwenden.

Bewahren Sie für jedes Ereignis den Kontext dazu auf, wann, wo, wer und was geschehen ist: Zeitstempel, Interaktionskennung, Aktion, Ergebnis, angewendete Regel und Vertrauensniveau. Verwenden Sie gegebenenfalls pseudonymisierte Kennungen oder geschützte Referenzen für Konto, Nummer, Gerät oder Sitzung.

Protokollieren Sie keine OTP-Geheimnisse, Passwörter, Zugriffstoken, Sitzungswerte oder unnötigen personenbezogenen Daten. Wenden Sie je nach Fall Maskierung, Hashing, Verschlüsselung oder Pseudonymisierung an und stellen Sie sicher, dass Zugriffsrechte für Logs der Sensibilität der Daten entsprechen.

• Interaktions- oder Transaktions-ID, um Anfrage, Versand und Validierung zu korrelieren.
• Zeitstempel, Aktion, Ergebnis und Grund der Entscheidung.
• Regelkennung, begrenzte Entität und Quotenstatus, ohne Geheimnisse offenzulegen.
• Pseudonymisierte Referenz auf das Ziel und andere für die Korrelation erforderliche Signale.
• Technischer Herkunftskontext nur in dem für Sicherheit und Untersuchung erforderlichen Umfang.
• Ereignisse zu Ausnahmen, manueller Überprüfung und Rücknahme zur Wahrung der Nachvollziehbarkeit.