Latenzbudget für SMS-OTP: Ablaufzeit und Ziele ohne Mittelwert definieren
Erfahren Sie, wie Sie die Latenz eines SMS-OTP mit Perzentilen, Segmentierung und funktionalen Signalen aufschlüsseln, messen und steuern – ohne Annahme, DLR und tatsächliche Codeverwendung zu verwechseln.
Welches Problem ein Latenzbudget in einem SMS-OTP-Ablauf löst
Ein SMS-OTP-Latenzbudget macht aus einer ungenauen Erwartung – „Der Code muss schnell ankommen“ – ein messbares Betriebsmodell. Es trennt die Phasen des Ablaufs, ordnet Verantwortlichkeiten zu, wählt beobachtbare Signale aus und legt fest, wie lange ein Code gültig bleibt, ohne sich auf eine globale durchschnittliche Zustellzeit zu stützen.
Bei einem Out-of-Band-Authentifizierungsablauf erzeugt der Verifizierer ein temporäres Geheimnis, sendet es über einen sekundären Kanal wie SMS und die nutzende Person übermittelt es über den primären Kanal zurück. Der relevante Ablauf endet daher nicht, wenn eine Plattform die Sendeanfrage annimmt, und auch nicht zwingend mit einem Zustellbericht: Er endet, wenn der Verifizierer eine gültige Eingabe des OTP akzeptiert.
Das Budget unterstützt Produkt- und Betriebsentscheidungen: eine angemessene Ablaufzeit definieren, festlegen, wann die Option zum erneuten Versand angezeigt wird, Verschlechterungen nach Ziel oder Route erkennen und vermeiden, dass dem Mobilfunknetz Verzögerungen zugeschrieben werden, die in der Anwendung oder einer internen Warteschlange entstehen.
- Definieren Sie das funktionale Ergebnis als erfolgreiche OTP-Validierung, nicht nur als Nachrichtenversand.
- Modellieren Sie die Phasen getrennt, bevor Sie Zeitziele festlegen.
- Messen Sie nach operativen Segmenten; ein globaler Wert kann konzentrierte Verschlechterungen verbergen.
- Behandeln Sie Sicherheit als Gestaltungsbeschränkung: Der Code muss temporär sein und darf nur einmal akzeptiert werden.
Warum die durchschnittliche Latenz nicht zur Festlegung der Code-Ablaufzeit taugt
Der Mittelwert beantwortet eine entscheidende Produktfrage schlecht: Wie viel Zeit benötigt die große Mehrheit legitimer Nutzerinnen und Nutzer, um den Ablauf abzuschließen? Eine Gruppe sehr schneller Zustellungen kann den Mittelwert senken, obwohl es einen erheblichen langen Bereich langsamer Erfahrungen gibt. Wird die Ablaufzeit anhand dieses Mittelwerts festgelegt, laufen Fälle am Ende der Verteilung wiederholt ab, obwohl die aggregierte Kennzahl gesund aussieht.
Die Ablaufzeit umfasst zudem nicht nur den SMS-Transport. Sie muss die Zeit von der Erstellung des Geheimnisses bis zu dessen Eingabe und Validierung abdecken, einschließlich interner Verarbeitung, Übertragung, möglicher Netzverzögerungen, Verfügbarkeit des Endgeräts und der Zeit, die die nutzende Person zum Lesen und Eingeben des Codes benötigt.
NIST weist darauf hin, dass bei zeitbasierten OTPs die Gültigkeitsdauer die erwartete Uhrabweichung, eine Toleranz für Netzverzögerungen und die Eingabezeit durch die nutzende Person berücksichtigen muss. Dieses Prinzip verhindert, dass eine Ablaufzeit auf Basis nur einer einzelnen Latenzmessung eines Anbieters oder einer Route entworfen wird.
- Verwenden Sie den Mittelwert weder als primäres Kriterium für die Ablaufzeit noch als einzigen SLO.
- Betrachten Sie hohe Perzentile der Zeit bis zur Validierung zusammen mit Erfolgs- und Ablaufquoten.
- Analysieren Sie vergleichbare Zeitfenster, nicht nur historische Aggregate.
- Unterscheiden Sie zwischen Transportverzögerung und später Validierung durch die Interaktion der nutzenden Person.
Operative Definitionen und minimale Zeitstempel
Definieren Sie vor der Messung jedes Ereignis präzise und erfassen Sie seinen Zeitstempel. Mehrdeutige Definitionen führen zu ungültigen Vergleichen zwischen Teams, Anbietern oder Zielen. Verwenden Sie eine interne Korrelations-ID für den Authentifizierungsversuch und eine Nachrichten-ID für den Versand, wobei Korrelationsdaten nicht sensibel sein sollten.
Eine praktische Sequenz beginnt mit der OTP-Erstellung und seiner Zuordnung zur Authentifizierungstransaktion. Anschließend werden die Anfrage an den Versandkanal, die Annahme dieser Anfrage per API oder SMPP, verfügbare Warteschlangen- und Versandereignisse, eingehende DLRs und schließlich die erfolgreiche oder fehlgeschlagene Codevalidierung erfasst.
Die Annahme per API oder SMPP bestätigt lediglich, dass der Anbieter den Befehl oder die Anfrage korrekt empfangen hat. Sie bestätigt nicht, dass die SMS das Gerät erreicht hat. Ebenso ist ein DLR ein asynchrones Signal, dessen Bedeutung vom erhaltenen Bericht und der Zustellkette abhängt; er sollte als betrieblicher Nachweis gespeichert werden, ohne ihn als Lesebestätigung oder endgültige Zustelluhr zu behandeln.
- t0: OTP-Erstellung und Beginn seiner Gültigkeitsdauer.
- t1: Von der Anwendung ausgelöste Sendeanfrage.
- t2: Annahme per API oder SMPP und, sofern vorhanden, Zuweisung der Nachrichten-ID.
- t3: In der Plattform verfügbare Versand- oder Statusänderungsereignisse.
- t4: Eingang des DLR sowie, falls bereitgestellt, die im Bericht selbst enthaltenen Zeitstempel und Versuche.
- t5: Eingabe und erfolgreiche Validierung des OTP oder Erfassung von Ablauf, Fehler oder Abbruch.
Welche Teile jeder Akteur kontrolliert
Der Absender kontrolliert die Gestaltung der Nutzungserfahrung, die Codegenerierung, die Erstellung der Anfrage, das Verhalten der Anwendung, eigene Warteschlangen, Ablaufregeln, Versuchslimits und die Instrumentierung. Er kann außerdem die verfügbare Konnektivität wählen, Richtlinien nach Ziel definieren und entsprechend seinen Vereinbarungen und betrieblichen Kontrollen auf Routen einwirken.
Der Messaging-Anbieter und Zwischenhändler kontrollieren je nach Architektur und geltenden Vereinbarungen Teile der Annahme, Verarbeitung und Zustellung zu verbundenen Netzen. Das Mobilfunknetz kontrolliert Elemente der Weiterleitung und der innerhalb seines Bereichs gemeldeten Zustellung. Endgerät, verfügbare Netzabdeckung, Gerätezustand und Verhalten der nutzenden Person liegen außerhalb der direkten Kontrolle des Absenders.
Diese Trennung sollte sich in der Diagnose widerspiegeln. Steigt die Zeit zwischen Erstellung und Annahme, untersuchen Sie zuerst die Anwendung oder die ausgehende Konnektivität. Bleibt die Annahme stabil, während sich die Verteilung von DLRs oder Validierungen für ein Ziel verändert, untersuchen Sie das betroffene Segment, ohne aus einem einzelnen Ereignis auf eine Ursache zu schließen.
- Anwendung: Generierung, sichere Speicherung, Ablaufzeit, Benutzeroberfläche, Anfrage und Validierung.
- Versandkonnektivität: Annahme, technische Antwort und Nachrichten-IDs.
- Route und Mobilfunknetz: Zustellverarbeitung und möglicherweise gemeldete Statussignale.
- Endgerät und nutzende Person: praktische Verfügbarkeit, Lesen und Eingabe des Codes.
- Verifizierer: endgültige Entscheidung, das eingegebene OTP anzunehmen oder abzulehnen.
Ein Latenzbudget nach Phasen erstellen
Erstellen Sie das Budget ausgehend vom relevanten Ergebnis: einer gültigen Validierung vor Ablauf. Beginnen Sie mit der Zusammenführung von Ereignissen realer Authentifizierungsversuche und korrelieren Sie Versuch, Nachricht und Verifizierungsergebnis. Schließen Sie Ereignisse, die nicht zuverlässig verknüpft werden können, aus der Definition aus, quantifizieren Sie jedoch diese fehlende Korrelation als Einschränkung der Beobachtbarkeit.
Berechnen Sie Verteilungen für jedes Intervall: Erstellung bis Anfrage, Anfrage bis Annahme, Annahme bis zu jedem verfügbaren Folgesignal sowie Erstellung bis erfolgreiche Validierung. Halten Sie validierte, abgelaufene, abgebrochene und fehlgeschlagene Versuche sowie Versuche mit falschem Code getrennt. Werden sie in einer einzigen Reihe zusammengeführt, verdeckt dies Sicherheits-, UX- und Zustellprobleme.
Das endgültige Budget ist kein Versprechen, dass alle Nachrichten innerhalb einer festen Zeit abgeschlossen werden. Es ist eine Richtlinie: ein Gültigkeitsfenster ergänzt um Limits für erneuten Versand, Versuchskontrollen, gegebenenfalls alternative Authentifizierungsverfahren und operative Schwellenwerte nach Segment.
- 1. Definieren Sie das Startzeitpunkt: normalerweise die OTP-Erstellung.
- 2. Definieren Sie das funktionale Endereignis: erfolgreiche Validierung durch den Verifizierer.
- 3. Erfassen Sie Zwischenintervalle mit unterscheidbaren Zeitstempeln.
- 4. Klassifizieren Sie das Ergebnis aller Versuche.
- 5. Berechnen Sie Perzentile nach Segment und Zeitfenster.
- 6. Legen Sie die Ablaufzeit unter Berücksichtigung von Transport, menschlicher Interaktion und Sicherheitsanforderungen fest.
- 7. Überprüfen Sie die Richtlinie nach Änderungen an Route, Produkt, Konnektivität oder Verkehrsverhalten.
Perzentile, Zeitfenster und Segmentierung nach Ziel
Verwenden Sie Perzentile, um die Verteilung zu beschreiben, nicht nur einen zentralen Punkt. Perzentile der Zeit bis zur Validierung helfen, die Erfahrung des langsameren Teils der Nutzerinnen und Nutzer zu beobachten, die den Ablauf abschließen. Sie müssen zusammen mit dem Anteil abgelaufener Versuche, der Validierungsrate und dem Volumen gelesen werden, da ein Perzentil auf wenigen Beobachtungen instabil sein kann.
Segmentieren Sie mindestens nach Ziel. Wenn Daten und Volumen es zulassen, ergänzen Sie für den Betrieb nützliche Dimensionen: Route, Absender, Nummerntyp, Verkehrsart, Anwendungsversion oder Risikorichtlinie. Vermischen Sie keine Segmente mit unterschiedlichem Verhalten und erwarten Sie anschließend nicht, dass ein einzelner globaler Schwellenwert die Ursache einer Abweichung erklärt.
Vergleichen Sie jedes Segment in konsistenten Zeitfenstern mit seiner eigenen Referenzlinie. Ein zu kurzes Fenster reagiert auf Rauschen; ein zu langes kann die Erkennung verzögern. Legen Sie außerdem ein Mindestvolumen an Beobachtungen fest, bevor Sie automatisierte Entscheidungen treffen oder einen Alarm eskalieren.
- Messen Sie die Zeit von Erstellung bis Validierung als wichtigste funktionale Kennzahl.
- Messen Sie Erstellung bis Annahme, um interne Verzögerungen oder Konnektivitätsprobleme einzugrenzen.
- Bewahren Sie DLRs und ihre Zeitstempel als ergänzende Telemetrie auf, nicht als Ersatz für die Validierung.
- Analysieren Sie Ablaufquote, erneute Versendungen, fehlgeschlagene Versuche und erfolgreiche Validierungen zusammen mit den Zeiten.
- Fordern Sie ausreichendes Volumen, bevor Sie Perzentile zwischen Segmenten vergleichen.
Ablaufzeit, erneuter Versand, Anfragelimits und Vermeidung von Duplikaten
Das Ablaufzeitfenster sollte breit genug sein, um die erwartete legitime Nutzungserfahrung abzudecken, darf aber kein Ersatz für Sicherheitskontrollen werden. Bei von NIST abgedeckter Out-of-Band-Authentifizierung muss die Transaktion innerhalb von 10 Minuten abgeschlossen werden, und ein bestimmtes Geheimnis darf während seiner Gültigkeitsdauer nur einmal akzeptiert werden. Wenden Sie stets die für Ihren Anwendungsfall geltenden regulatorischen, vertraglichen und risikobezogenen Anforderungen an.
Ein erneuter Versand darf weder einen Nachrichtensturm auslösen noch die Angriffsfläche unbegrenzt erweitern. Prüfen Sie vor dem Versand einer weiteren SMS, ob ein gültiges OTP für dieselbe Transaktion existiert, und entscheiden Sie ausdrücklich, ob es wiederverwendet, ungültig gemacht und ersetzt oder die Anfrage begrenzt wird. Die Richtlinie muss konsistent sein, damit nicht mehrere mehrdeutige aktive Codes ohne klare Validierungsregel bestehen.
Bei kurzen Geheimnissen müssen aufeinanderfolgende fehlgeschlagene Versuche wirksam begrenzt werden. Die Ausgabe eines neuen Geheimnisses darf den Zähler fehlgeschlagener Versuche nicht zurücksetzen. Sie können progressive Wartezeiten und Risikosignale einsetzen, um den Ablauf bei auffälligen Mustern zu verschärfen, und zugleich alternative Authentifizierungsverfahren anbieten, wenn Risiko, Abdeckung oder Barrierefreiheit dies erfordern.
- Führen Sie einen einzigen autoritativen Status je Authentifizierungstransaktion.
- Machen Sie jedes OTP nur einmal verwendbar.
- Definieren Sie ausdrücklich, was nach einem erneuten Versand mit dem vorherigen OTP geschieht.
- Begrenzen Sie Anfragen zum erneuten Versand nach Konto, Sitzung, Ziel und relevanten Risikosignalen.
- Setzen Sie Limits für fehlgeschlagene Versuche bei Ausgabe eines neuen Codes nicht zurück.
- Bieten Sie alternative Authentifizierungsverfahren an, wenn SMS/PSTN ungeeignet oder nicht verfügbar ist.
Was ein DLR anzeigen kann und was es nicht belegen kann
Ein DLR kann nützliche betriebliche Informationen liefern: gemeldeten Status, Zustellversuche und je nach Schnittstelle Zeitstempel des Versuchs und des Berichtseingangs. Es ist wertvoll, um Trends zu untersuchen und eine anfängliche technische Antwort von einem später gemeldeten Zustellstatus zu unterscheiden.
Ein DLR belegt jedoch nicht für sich allein, dass die nutzende Person den Code gelesen, verstanden oder eingegeben hat. Es sollte auch nicht als Uhr verwendet werden, um unmittelbar auf eine Verzögerung der Zustellung zu schließen. Von Betreibern erzeugte Belege oder Ereignisse können verspätet eintreffen; die AWS-Dokumentation weist darauf hin, dass sie bis zu 72 Stunden später eintreffen können und nicht zur Bestimmung einer Verzögerung ausgehender Zustellungen verwendet werden sollten.
Die erfolgreiche OTP-Validierung ist ein stärkeres funktionales Signal: Sie zeigt, dass der Code für die nutzende Person verfügbar wurde und dem Verifizierer vorgelegt wurde. Dennoch wird das DLR dadurch nicht irrelevant; beide Signale beantworten unterschiedliche Fragen und sollten getrennt aufbewahrt werden.
- Versandannahme: Der Befehl oder die Anfrage wurde korrekt empfangen.
- DLR: asynchron gemeldetes Zustellergebnis mit Unsicherheit hinsichtlich Zeitpunkt und Aussagekraft.
- Erfolgreiche Validierung: funktionaler Nachweis, dass der Code dem Verifizierer korrekt vorgelegt wurde.
- Fehlendes DLR: darf nicht automatisch als fehlende Zustellung interpretiert werden.
- DLR Delivered: belegt weder das Lesen noch die korrekte Eingabe des Codes.
Häufige Fragen
Welche Kennzahl sollte die Ablaufzeit eines SMS-OTP bestimmen?
Der nützlichste Bezugspunkt ist die Verteilung der Zeit von der OTP-Erstellung bis zur erfolgreichen Validierung, segmentiert nach Ziel und weiteren relevanten operativen Dimensionen. Sie sollte durch Ablauf-, erneute Versand- und Fehlerraten ergänzt werden, nicht durch einen isolierten durchschnittlichen Zustellwert.
Bedeutet die Annahme per API oder SMPP, dass die SMS auf dem Telefon angekommen ist?
Nein. Sie zeigt an, dass der Befehl oder die Anfrage vom annehmenden System korrekt empfangen wurde. Sie belegt nicht den Empfang auf dem Zielgerät.
Beweist ein DLR Delivered, dass der Nutzer das OTP empfangen und gelesen hat?
Nein. Ein DLR stellt ein gemeldetes Zustellergebnis dar und kann als operatives Signal nützlich sein, belegt aber nicht das Lesen, Verstehen oder Eingeben des Codes. Die erfolgreiche Validierung ist das stärkere funktionale Signal.
Wie lange sollte ein per SMS versendetes OTP gültig sein?
Es gibt keine universelle Dauer, die aus einem durchschnittlichen Zustellwert abgeleitet werden kann. Legen Sie sie anhand der Verteilung der Zeiten bis zur Validierung, der erwarteten Interaktionszeit, des Risikos und der geltenden Anforderungen fest. Bei von NIST abgedeckter Out-of-Band-Authentifizierung muss die Transaktion innerhalb von 10 Minuten abgeschlossen werden.
Sollte bei jeder Anfrage zum erneuten Versand ein neuer Code erzeugt werden?
Es muss eine ausdrückliche Richtlinie geben. Wenn ein neuer Code erzeugt wird, legen Sie fest, was mit dem vorherigen geschieht, um Mehrdeutigkeiten zu vermeiden, und setzen Sie Kontrollen für fehlgeschlagene Versuche nicht zurück. Außerdem sollten Anfragen zum erneuten Versand begrenzt sowie gegebenenfalls Wartezeiten oder adaptive Maßnahmen angewendet werden.
Wie lässt sich eine Verschlechterung einer OTP-Route erkennen?
Vergleichen Sie Perzentile der Zeit bis zur Validierung, Ablaufquoten, erneute Versendungen und Zustellsignale mit einer eigenen Referenzlinie, segmentiert nach Ziel, Route, Absender oder anderen verfügbaren Dimensionen. Fordern Sie ausreichendes Volumen und eine anhaltende Abweichung, bevor Sie einen isolierten Ausschlag einem Routenproblem zuschreiben.
Verwendete Quellen
- NIST SP 800-63B: autenticación fuera de banda y secretos temporalesNational Institute of Standards and Technology (NIST)
- AWS End User Messaging SMS User Guide: eventos, DLR y feedback de mensajesAmazon Web Services (AWS)
- Azure Communication Services SMS Delivery Reports APIMicrosoft
- Azure Communication Services: eventos SMSMicrosoft
- OWASP Authentication Cheat SheetOWASP Foundation