Wenn eine E-Mail zum Kontozugriff verspätet eintrifft, fordern Benutzer häufig mehrere weitere E-Mails an. Dies kann zu doppelten Nachrichten, verwirrenden Gültigkeitsfenstern und zusätzlicher Warteschlangenbelastung führen. Diagnostizieren Sie den Weg von der Anfrage bis zur erfolgreichen Nutzung, bevor Sie DNS beschuldigen oder die Lebensdauer jedes Tokens verlängern.
Erstellen Sie eine redigierte Ereigniszeitleiste
Verwenden Sie eine interne Korrelationskennung, um die akzeptierte Anforderung, das erstellte Token, den in die Warteschlange gestellten Job, den vom Anbieter akzeptierten, die Empfängerantwort und den eingelösten oder abgelehnten Token zu verknüpfen. Tragen Sie das Token, die Reset-URL oder das OTP nicht in Routineprotokolle ein. Erfassen Sie Kennungen und Ursachenkategorien mit streng eingeschränktem Zugriff auf alle Nachrichtenbeispiele, die zur Fehlerbehebung erforderlich sind.
SMTP Akzeptanz bedeutet, dass ein Server zu diesem Zeitpunkt die Verantwortung übernommen hat; Es zeigt weder die Platzierung im Posteingang noch einen Menschen, der die Nachricht liest. Behalten Sie diesen Unterschied bei den Support-Tools bei. RFC 5321.
Anleitung zur OWASP-Protokollierung unterstützt die Korrelation und schließt Geheimnisse aus Routineprotokollen aus.
Trennen Sie die Authentifizierung von der Anwendungsgültigkeit
Überprüfen Sie die endgültigen kontrollierten Nachrichten auf die beabsichtigten Absenderidentitäten und die Authentifizierungsergebnisse des vertrauenswürdigen Empfängers. Eine veraltete Anbieterkonfiguration kann diesen Weg unterbrechen, selbst wenn Newsletter funktionieren. Umgekehrt kann das Bestehen der E-Mail-Authentifizierung nicht dazu führen, dass ein abgelaufenes oder bereits verwendetes Anwendungstoken gültig wird.
OWASP empfiehlt sicher generierte Einweg-Tokens oder -Codes mit angemessenem Ablaufdatum, sicherer Speicherung und Schutz vor Kontoaufzählung und übermäßigen Anfragen. Die Anleitung zum Zurücksetzen von Passwörtern stellt die Sicherheitsbasis für Rücksetzabläufe dar, kein Versprechen zur Latenz bei der E-Mail-Zustellung. OWASP-Anleitung „Passwort vergessen“..
Per E-Mail zugestellte Codes für andere Authentifizierungszwecke erfordern eine eigene Sicherheitsbewertung. Beschreiben Sie den Besitz von E-Mails nicht als Phishing-resistente Authentifizierung und gehen Sie nicht davon aus, dass eine Empfehlung zum Zurücksetzen des Passworts jede OTP-Bereitstellung genehmigt. Im Rahmen seiner Anforderungen an die digitale Identität verbietet NIST E-Mail als Out-of-Band-Authentifikator und unterscheidet dabei Adressbestätigungs- und Wiederherstellungscodes von diesem Verbot. NIST SP 800-63B-4 Abschnitte 3.1.3 und 3.1.3.1.
Erarbeiten Sie das Gültigkeitsbudget
Ein hypothetischer Zeitplan legt die Token-Erstellung um 09:00:00 und den Ablauf um 09:05:00 fest. Die Annahme durch den Anbieter erfolgt um 09:00:10 , die Annahme durch den Empfänger um 09:04:40 und die beispielhafte Benutzeraktion um 09:05:20 . Bei Annahme des Empfängers verbleiben nur noch 20 Sekunden; Die Aktion erfolgt 20 Sekunden nach Ablauf.
Gemäß einer erklärten Richtlinie, dass ein Token bei oder nach seinem Ablauf ungültig ist, würde sich ein ansonsten gültiger, unbenutzter Token, der in Sekunde 299 vorgelegt wird, immer noch innerhalb dieses Fünf-Minuten-Fensters befinden, während dies in den Sekunden 300 oder 301 nicht der Fall wäre. Ein bereits eingelöster Token darf nicht nur aufgrund der verbleibenden Zeit wiederverwendbar werden. Hierbei handelt es sich um erwartete Ergebnisse im Rahmen der erfundenen Richtlinie, nicht um durchgeführte Token-Prüfungen oder eine empfohlene universelle Lebensdauer.
Die umsetzbare Frage ist, wo die 280 Sekunden zwischen der Erstellung und der Annahme durch den Empfänger geblieben sind. Die Akzeptanz des Anbieters in Sekunde 10 beweist nicht, dass die nächsten 270 Sekunden vollständig bei einem Anbieter verbracht wurden; Erhalten Sie Warteschlangen- und Antwortnachweise, bevor Sie die Verantwortung zuweisen. Die Sichtbarkeit des Posteingangs bleibt unbekannt. Es wurde kein echter Token, kein Produktionskonto oder keine Lieferung getestet.
Reparieren Sie die fehlgeschlagene Phase
Wenn die Anwendungswarteschlange zu langsam ist, priorisieren Sie die Arbeitslast beim Kontozugriff und beseitigen Sie vermeidbare Batch-Verzögerungen. Wenn der Anbieter vorübergehende Fehler meldet, überprüfen Sie die vollständigen Antworten und die unterstützte Wiederholungsbehandlung. Wenn das Token durch eine neuere Anfrage ungültig wird, machen Sie dieses Verhalten verständlich, ohne einem nicht authentifizierten Anforderer offenzulegen, ob ein Konto existiert.
Verwenden Sie Ratenlimits und klare generische Anfrageantworten, um zu verhindern, dass wiederholte Klicks zu einer E-Mail-Flut führen. Gleichen Sie Wiederholungsversuche mit der Token-Richtlinie der Anwendung ab. Durch das blinde erneute Senden einer alten Nachricht kann ein bereits ungültiges Token übermittelt werden, während die Ausgabe unbegrenzter neuer Token das Missbrauchsrisiko erhöhen kann.
Überprüfen Sie, ohne Geheimnisse zu protokollieren
Testen Sie genehmigte kontrollierte Konten über relevante Ziele hinweg und zeichnen Sie Phasenlatenz, Ablaufergebnis und Duplikathandhabung auf. Jede Änderung am Ablauf, der Token-Generierung oder der Kontowiederherstellung erfordert eine Sicherheitsüberprüfung. Die Verlängerung der Lebensdauer ist kein Ersatz für die Behebung von Warteschlangen.
Schließen Sie den Vorfall mit einer phasenspezifischen Ursache, einer umfassenden Behebung und einer gemessenen Customer Journey ab. Machen Sie die verbleibenden Sichtbarkeitslücken deutlich. Der Support sollte in der Lage sein zu erklären: „Vom Empfänger akzeptiert, Gültigkeitsfenster ausgeschöpft“, ohne zu behaupten, dass ein Kunde die Nachricht gelesen oder seine Anmeldedaten preisgegeben hat.
Wählen Sie den Eigentümer aus der fehlgeschlagenen Phase aus
Die Warteschlangenverzögerung liegt in der Verantwortung der Anwendung oder des sendenden Betreibers. Eine ausdrückliche Annahmeverweigerung gehört zur Streckenermittlung; Ein abgelaufenes oder bereits verwendetes Ergebnis gehört zur Token-Richtlinie und zum Anwendungsstatus. Bewahren Sie einen redigierten Korrelationsdatensatz auf und lassen Sie den entsprechenden Eigentümer einen genehmigten erneuten Test definieren.