Når en e-mail med kontoadgang ankommer for sent, anmoder brugerne ofte om flere. Det kan skabe duplikerede meddelelser, forvirrende gyldighedsvinduer og ekstra købelastning. Diagnostiser rejsen fra anmodning til vellykket brug, før du giver DNS skylden eller forlænger hvert tokens levetid.
Byg en redigeret begivenhedstidslinje
Brug et internt korrelations-id til at deltage i anmodningen accepteret, token oprettet, job i kø, udbyder accepteret, modtagersvar og token indløst eller afvist. Indsæt ikke token, nulstil URL eller OTP i rutinelogfiler. Registrer identifikatorer og årsagskategorier med strengt begrænset adgang til enhver meddelelsesprøve, der kræves til fejlfinding.
SMTP accept betyder, at en server har påtaget sig ansvaret på det tidspunkt; det viser ikke indbakkeplacering eller et menneske, der læser beskeden. Bevar denne sondring i støtteværktøj. RFC 5321.
OWASP logføringsvejledning understøtter korrelation og udelukker hemmeligheder fra rutinelogfiler.
Adskil godkendelse fra applikationsgyldighed
Undersøg endelige kontrollerede meddelelser for de tilsigtede afsenderidentiteter og betroede modtagergodkendelsesresultater. En forældet leverandørkonfiguration kan bryde denne rute, selv mens nyhedsbreve fungerer. Omvendt kan godkendelse af e-mail ikke gøre et udløbet eller allerede brugt programtoken gyldigt.
OWASP anbefaler sikkert genererede engangstokens eller koder med passende udløb, sikker opbevaring og beskyttelse mod kontooptælling og overdrevne anmodninger. Dens vejledning til nulstilling af adgangskode giver sikkerhedsgrundlaget for nulstillingsflows, ikke et løfte om e-mail-leveringsforsinkelse. OWASP Glemt adgangskode vejledning.
E-mail-leverede koder til anden godkendelsesanvendelse kræver deres egen sikkerhedsvurdering. Beskriv ikke besiddelse af e-mail som phishing-resistent godkendelse, og antag ikke, at en anbefaling til nulstilling af adgangskode godkender enhver OTP-implementering. Inden for sine krav til digital identitet forbyder NIST e-mail som en out-of-band-godkendelse, mens den skelner adressebekræftelse og gendannelseskoder fra dette forbud. NIST SP 800-63B-4 afsnit 3.1.3 og 3.1.3.1.
Arbejd med gyldighedsbudgettet
En hypotetisk tidslinje angiver tokenoprettelse kl. 09:00:00 og udløber kl 09:05:00 . Udbyderens accept sker kl. 09:00:10 , modtagerens accept kl. 09:04:40 og den illustrative brugerhandling kl. 09:05:20 . Der er kun 20 sekunder tilbage ved modtagerens accept; handlingen sker 20 sekunder efter udløbet.
Under en erklæret politik om, at et token er ugyldigt ved eller efter dets udløb, vil et ellers gyldigt ubrugt token, der præsenteres ved anden 299, stadig være inden for dette fem-minutters vindue, mens præsentation ved sekunder 300 eller 301 ikke ville. En token, der allerede er indløst, må ikke blive genbrugelig, blot fordi der er tid tilbage. Disse er forventede resultater under den opfundne politik, ikke udførte token-tjek eller en anbefalet universel levetid.
Det praktiske spørgsmål er, hvor de 280 sekunder mellem oprettelsen og modtagerens accept blev af. Udbyderens accept ved anden 10 beviser ikke, at de næste 270 sekunder blev brugt helt inden for én udbyder; indhente kø- og svarbevis, før du tildeler ansvaret. Indbakkens synlighed er stadig ukendt. Ingen ægte token, produktionskonto eller levering blev testet.
Reparer den mislykkede fase
Hvis applikationen står for langsomt i kø, skal du prioritere arbejdsbyrden for kontoadgang og fjerne undgåelige batchforsinkelser. Hvis udbyderen rapporterer midlertidige fejl, skal du inspicere fuldstændige svar og understøttet genforsøgshåndtering. Hvis tokenet er ugyldigt af en nyere anmodning, skal du gøre denne adfærd forståelig uden at afsløre, om der findes en konto, for en ikke-godkendt anmoder.
Brug hastighedsgrænser og tydelige generiske anmodningssvar for at forhindre gentagne klik i at blive en e-mail-flom. Afstem genforsøg med applikationens tokenpolitik. Blinde gensending af en gammel besked kan levere et token, der allerede er ugyldigt, mens udstedelse af ubegrænset nye tokens kan øge risikoen for misbrug.
Bekræft uden at logge hemmeligheder
Test godkendte kontrollerede konti på tværs af relevante destinationer, og registrer faseforsinkelse, udløbsresultat og duplikathåndtering. Enhver ændring af udløb, tokengenerering eller kontogendannelse kræver sikkerhedsgennemgang; forlængelse af levetiden er ikke en erstatning for fiksering af køer.
Luk hændelsen med en fasespecifik årsag, scoped afhjælpning og målt kunderejse. Hold de resterende synlighedshuller eksplicitte. Support bør være i stand til at forklare "accepteret af modtageren, gyldighedsvinduet er opbrugt" uden at påstå, at en kunde har læst beskeden eller afsløret deres legitimationsoplysninger.
Vælg ejeren fra den fejlende fase
Køforsinkelse tilhører applikationen eller afsenderoperatøren; et eksplicit modtagelsesafslag hører med til ruteundersøgelse; et udløbet eller allerede brugt resultat hører til tokenpolitikken og applikationstilstanden. Behold én redigeret korrelationspost, og få den relevante ejer til at definere en godkendt gentest.