Når en e-post med kontotilgang kommer for sent, ber brukere ofte om flere. Det kan skape dupliserte meldinger, forvirrende gyldighetsvinduer og ekstra købelastning. Diagnostiser reisen fra forespørsel til vellykket bruk før du legger skylden på DNS eller forlenger levetiden til hvert token.
Bygg en redigert hendelsestidslinje
Bruk en intern korrelasjonsidentifikator for å bli med i forespørsel akseptert, token opprettet, jobb i kø, leverandør akseptert, mottakersvar og token innløst eller avvist. Ikke legg token, tilbakestill URL eller OTP i rutinelogger. Registrer identifikatorer og årsakskategorier med strengt begrenset tilgang til alle meldingseksempler som kreves for feilsøking.
SMTP aksept betyr at en server har akseptert ansvar på det stadiet; den viser ikke innboksplassering eller at et menneske leser meldingen. Bevar denne forskjellen i støtteverktøy. RFC 5321.
OWASP-loggingsveiledning støtter korrelasjon mens hemmeligheter utelukkes fra rutinelogger.
Skill autentisering fra applikasjonsgyldighet
Inspiser endelige kontrollerte meldinger for de tiltenkte avsenderens identiteter og pålitelige mottakerautentiseringsresultater. En foreldet leverandørkonfigurasjon kan bryte denne ruten selv mens nyhetsbrev fungerer. Motsatt kan ikke bestått e-postautentisering gjøre et utløpt eller allerede brukt programtoken gyldig.
OWASP anbefaler sikkert genererte engangstokener eller koder med passende utløp, sikker lagring og beskyttelse mot kontooppregning og overdrevne forespørsler. Veiledningen for tilbakestilling av passord gir sikkerhetsgrunnlaget for tilbakestillingsflyter, ikke et løfte om forsinkelse av e-postlevering. OWASP Glemt passord veiledning.
E-postleverte koder for annen autentiseringsbruk krever sin egen sikkerhetsvurdering. Ikke beskriv e-postbesittelse som phishing-resistent autentisering, og ikke anta at en anbefaling for tilbakestilling av passord godkjenner hver OTP-distribusjon. Innenfor kravene til digital identitet, forbyr NIST e-post som en autentisering utenfor båndet, mens den skiller adressebekreftelse og gjenopprettingskoder fra dette forbudet. NIST SP 800-63B-4 avsnitt 3.1.3 og 3.1.3.1.
Arbeid gyldighetsbudsjettet
En hypotetisk tidslinje angir tokenoppretting kl. 09:00:00 og utløper kl 09:05:00 . Leverandørens aksept skjer kl. 09:00:10 , mottakerens aksept kl. 09:04:40 og den illustrative brukerhandlingen kl. 09:05:20 . Bare 20 sekunder gjenstår ved mottakerens aksept; handlingen skjer 20 sekunder etter utløp.
Under en erklært policy om at et token er ugyldig ved eller etter dets utløp, vil et ellers gyldig ubrukt token som presenteres ved andre 299 fortsatt være innenfor dette fem-minutters vinduet, mens presentasjon ved sekunder 300 eller 301 ikke ville. Et symbol som allerede er innløst, må ikke bli gjenbrukbart bare fordi det gjenstår tid. Dette er forventede utfall under den oppfunne policyen, ikke utførte token-sjekker eller en anbefalt universell levetid.
Det praktiske spørsmålet er hvor de 280 sekundene mellom opprettelsen og mottakerens aksept ble av. Leverandørens aksept ved andre 10 beviser ikke at de neste 270 sekundene ble brukt helt inne i én leverandør; innhente kø- og responsbevis før du tildeler ansvar. Innboksens synlighet er fortsatt ukjent. Ingen ekte token, produksjonskonto eller levering ble testet.
Reparer det mislykkede stadiet
Hvis applikasjonen står i kø for sakte, prioriter arbeidsbelastningen for kontotilgang og fjern forsinkelser som kan unngås. Hvis leverandøren rapporterer midlertidige feil, inspiser fullstendige svar og støttet håndtering på nytt. Hvis tokenet er ugyldiggjort av en nyere forespørsel, gjør denne oppførselen forståelig uten å avsløre om en konto eksisterer for en uautentisert forespørsel.
Bruk hastighetsgrenser og tydelige generiske forespørselssvar for å forhindre at gjentatte klikk blir en e-postflom. Avstem gjenforsøk med programmets tokenpolicy. Blindt å sende en gammel melding på nytt kan levere et token som allerede er ugyldig, mens utstedelse av ubegrensede nye tokens kan øke misbruksrisikoen.
Bekreft uten å logge hemmeligheter
Test godkjente kontrollerte kontoer på tvers av relevante destinasjoner og registrer stadiumforsinkelse, utløpsresultat og duplikathåndtering. Enhver endring av utløp, tokengenerering eller kontogjenoppretting trenger sikkerhetsgjennomgang; forlengelse av levetid er ikke en erstatning for å fikse køer.
Lukk hendelsen med en fasespesifikk årsak, omfangsrettet utbedring og målt kundereise. Hold gjenværende sikthull eksplisitt. Støtte skal kunne forklare "akseptert av mottakeren, gyldighetsvinduet er oppbrukt" uten å hevde at en kunde har lest meldingen eller avslørt legitimasjonen.
Velg eieren fra det feilende stadiet
Køforsinkelse tilhører applikasjonen eller avsenderoperatøren; et eksplisitt mottaksavslag hører med til ruteundersøkelse; et utløpt eller allerede brukt resultat tilhører token-policyen og applikasjonstilstanden. Behold én redigert korrelasjonspost og la den aktuelle eieren definere en godkjent retest.