Wanneer een e-mail met toegang tot een account te laat arriveert, vragen gebruikers er vaak meerdere. Dat kan leiden tot dubbele berichten, verwarrende geldigheidsperioden en extra wachtrijbelasting. Onderzoek het traject van aanvraag tot succesvol gebruik voordat u DNS de schuld geeft of de levensduur van elk token verlengt.
Bouw een geredigeerde gebeurtenistijdlijn
Gebruik een interne correlatie-ID om deel te nemen aan het geaccepteerde verzoek, het aangemaakte token, de taak in de wachtrij, de geaccepteerde provider, het antwoord van de ontvanger en het ingewisselde of afgewezen token. Plaats het token, de reset-URL of het OTP niet in routinelogboeken. Leg ID's en redencategorieën vast met strikt beperkte toegang tot elk berichtvoorbeeld dat nodig is voor het oplossen van problemen.
SMTP acceptatie betekent dat een server op dat moment de verantwoordelijkheid heeft aanvaard; het toont geen plaatsing in de inbox of een mens die het bericht leest. Behoud dat onderscheid in supporttools. RFC 5321.
OWASP-logboekbegeleiding ondersteunt correlatie terwijl geheimen uit routinelogboeken worden uitgesloten.
Scheid authenticatie van applicatiegeldigheid
Inspecteer definitief gecontroleerde berichten op de beoogde afzenderidentiteiten en authenticatieresultaten van vertrouwde ontvangers. Een verouderde leveranciersconfiguratie kan deze route doorbreken, zelfs als nieuwsbrieven werken. Omgekeerd kan het doorgeven van e-mailauthenticatie een verlopen of reeds gebruikt applicatietoken niet geldig maken.
OWASP beveelt veilig gegenereerde tokens of codes voor eenmalig gebruik aan met de juiste vervaldatum, veilige opslag en bescherming tegen accountopsomming en buitensporige verzoeken. De richtlijnen voor het opnieuw instellen van wachtwoorden bieden de beveiligingsbasislijn voor resetstromen, en geen belofte over de latentie van e-mailbezorging. OWASP Wachtwoord vergeten begeleiding.
Via e-mail geleverde codes voor ander authenticatiegebruik vereisen hun eigen beveiligingsbeoordeling. Beschrijf het bezit van e-mail niet als phishing-bestendige authenticatie, en ga er niet vanuit dat een aanbeveling voor het opnieuw instellen van het wachtwoord elke OTP-implementatie goedkeurt. Binnen de vereisten voor digitale identiteit verbiedt NIST e-mail als out-of-band authenticator, terwijl adresbevestigings- en herstelcodes worden onderscheiden van dat verbod. NIST SP 800-63B-4 paragrafen 3.1.3 en 3.1.3.1.
Werk met het geldigheidsbudget
Een hypothetische tijdlijn stelt de creatie van tokens in op 09:00:00 en vervalt op 09:05:00 . Acceptatie door de aanbieder vindt plaats om 09:00:10 , acceptatie door de ontvanger om 09:04:40 en de illustratieve gebruikersactie om 09:05:20 . Er resteren nog slechts 20 seconden bij acceptatie door de ontvanger; de actie vindt 20 seconden na het verstrijken plaats.
Onder een aangegeven beleid dat een token ongeldig is op of na de vervaldatum, zou een anderszins geldig ongebruikt token dat op seconde 299 wordt gepresenteerd nog steeds binnen dit tijdsbestek van vijf minuten vallen, terwijl presentatie op seconden 300 of 301 dat niet zou doen. Een token dat al is ingewisseld, mag niet herbruikbaar worden alleen maar omdat er nog tijd over is. Dit zijn verwachte resultaten onder het bedachte beleid, niet uitgevoerde tokencontroles of een aanbevolen universele levensduur.
De bruikbare vraag is waar de 280 seconden tussen creatie en acceptatie door de ontvanger zijn gebleven. Acceptatie door de aanbieder op seconde 10 bewijst niet dat de volgende 270 seconden volledig binnen één aanbieder zijn doorgebracht; wachtrij- en responsbewijs verkrijgen voordat de verantwoordelijkheid wordt toegewezen. De zichtbaarheid van de inbox blijft onbekend. Er is geen echt token, productieaccount of levering getest.
Repareer de mislukte fase
Als de applicatie te langzaam in de wachtrij staat, geef dan prioriteit aan de werklast voor accounttoegang en verwijder vermijdbare batchvertragingen. Als de provider tijdelijke fouten meldt, controleer dan de volledige reacties en de ondersteunde verwerking van nieuwe pogingen. Als het token ongeldig wordt gemaakt door een nieuwer verzoek, moet u dat gedrag begrijpelijk maken zonder aan een niet-geverifieerde aanvrager bekend te maken of er een account bestaat.
Gebruik snelheidslimieten en duidelijke algemene verzoekreacties om te voorkomen dat herhaalde klikken een e-mailoverstroming worden. Stem nieuwe pogingen af op het tokenbeleid van de toepassing. Het blindelings opnieuw versturen van een oud bericht kan een token opleveren dat al ongeldig is, terwijl het uitgeven van onbeperkt nieuwe tokens het risico op misbruik kan vergroten.
Verifieer zonder geheimen te loggen
Test goedgekeurde gecontroleerde accounts op relevante bestemmingen en registreer de latentie in de fase, het vervalresultaat en de afhandeling van duplicaten. Voor elke wijziging in de vervaldatum, het genereren van tokens of het herstellen van accounts is een veiligheidsbeoordeling vereist; Het verlengen van de levensduur is geen vervanging voor het oplossen van wachtrijen.
Sluit het incident af met een fasespecifieke oorzaak, een gerichte oplossing en een gemeten klantreis. Houd de resterende zichtbaarheidslacunes expliciet. Ondersteuning moet in staat zijn om uit te leggen “geaccepteerd door de ontvanger, geldigheidsperiode uitgeput” zonder te beweren dat een klant het bericht heeft gelezen of zijn inloggegevens openbaar heeft gemaakt.
Kies de eigenaar uit de mislukte fase
Wachtrijvertraging hoort bij de applicatie of verzendende operator; een expliciete ontvangstweigering hoort bij routeonderzoek; een verlopen of al gebruikt resultaat hoort bij het tokenbeleid en de applicatiestatus. Bewaar één geredigeerd correlatierecord en laat de relevante eigenaar een goedgekeurde hertest definiëren.