När ett e-postmeddelande med kontoåtkomst kommer sent begär användare ofta flera till. Det kan skapa dubbletter av meddelanden, förvirrande giltighetsfönster och extra köbelastning. Diagnostisera resan från begäran till framgångsrik användning innan du skyller på DNS eller förlänger varje tokens livstid.
Bygg en redigerad händelsetidslinje
Använd en intern korrelationsidentifierare för att gå med i begäran accepterad, token skapad, jobb i kö, leverantör accepterad, mottagarsvar och token inlöst eller avvisad. Placera inte token, återställ URL eller OTP i rutinloggar. Registrera identifierare och orsakskategorier med starkt begränsad åtkomst till alla meddelandeexempel som krävs för felsökning.
SMTP acceptans innebär att en server har accepterat ansvaret i det skedet; det visar inte placeringen i inkorgen eller att en människa läser meddelandet. Bevara den distinktionen i stödverktyg. RFC 5321.
OWASP-loggningsvägledning stöder korrelation samtidigt som hemligheter från rutinloggar utesluts.
Separera autentisering från applikationsgiltighet
Inspektera slutliga kontrollerade meddelanden för avsändaridentiteter och betrodda mottagarautentiseringsresultat. En inaktuell leverantörskonfiguration kan bryta denna väg även när nyhetsbrev fungerar. Omvänt kan godkänd e-postautentisering inte göra en utgången eller redan använd programtoken giltig.
OWASP rekommenderar säkert genererade tokens eller koder för engångsbruk med lämpligt utgångsdatum, säker lagring och skydd mot kontouppräkning och överdrivna förfrågningar. Dess vägledning för återställning av lösenord tillhandahåller säkerhetsbasen för återställningsflöden, inte ett löfte om e-postleveransfördröjning. OWASP Glömt lösenord vägledning.
E-postlevererade koder för andra autentiseringsanvändningar kräver en egen säkerhetsbedömning. Beskriv inte e-postinnehav som nätfiske-resistent autentisering, och anta inte att en rekommendation för lösenordsåterställning godkänner varje OTP-distribution. Inom sina krav på digital identitet förbjuder NIST e-post som autentisering utanför bandet samtidigt som adressbekräftelse och återställningskoder skiljer sig från det förbudet. NIST SP 800-63B-4 avsnitt 3.1.3 och 3.1.3.1.
Arbeta med giltighetsbudgeten
En hypotetisk tidslinje ställer in tokenskapande kl. 09:00:00 och löper ut kl. 09:05:00 . Leverantörsacceptans sker kl. 09:00:10 , mottagarens godkännande kl. 09:04:40 och den illustrativa användaråtgärden kl. 09:05:20 . Endast 20 sekunder återstår vid mottagarens acceptans; åtgärden inträffar 20 sekunder efter utgången.
Enligt en deklarerad policy att en token är ogiltig vid eller efter dess utgång, skulle en annars giltig oanvänd token som presenteras vid andra 299 fortfarande vara inom detta femminutersfönster, medan presentation vid sekunder 300 eller 301 inte skulle göra det. En token som redan har lösts in får inte bli återanvändbar bara för att tid återstår. Dessa är förväntade resultat enligt den uppfunna policyn, inte utförda tokenkontroller eller en rekommenderad universell livslängd.
Den praktiska frågan är var de 280 sekunderna mellan skapande och mottagaracceptans tog vägen. Leverantörsacceptans vid andra 10 bevisar inte att de följande 270 sekunderna spenderades helt inom en leverantör; skaffa kö- och svarsbevis innan du tilldelar ansvaret. Inkorgens synlighet är fortfarande okänd. Ingen riktig token, produktionskonto eller leverans testades.
Reparera det misslyckade steget
Om applikationen köar för långsamt, prioritera arbetsbelastningen för kontoåtkomst och ta bort förseningar som kan undvikas. Om leverantören rapporterar tillfälliga misslyckanden, inspektera fullständiga svar och stödd hantering av försök igen. Om token ogiltigförklaras av en nyare begäran, gör det beteendet begripligt utan att avslöja om det finns ett konto för en oautentiserad begärande.
Använd hastighetsgränser och tydliga generiska förfrågningssvar för att förhindra att upprepade klick blir en e-postflod. Stäm av återförsök med programmets tokenpolicy. Att blint skicka om ett gammalt meddelande kan leverera en token som redan är ogiltig, medan att utfärda obegränsat med nya tokens kan öka risken för missbruk.
Verifiera utan att logga hemligheter
Testa godkända kontrollerade konton över relevanta destinationer och registrera skedens latens, utgångsresultat och dubbletthantering. Alla ändringar av utgångsdatum, tokengenerering eller kontoåterställning kräver säkerhetsgranskning; att förlänga livslängden är inte en ersättning för att fixa köer.
Avsluta incidenten med en stadiespecifik orsak, omfattningsvis åtgärdande och uppmätt kundresa. Håll kvarvarande siktluckor tydliga. Support ska kunna förklara "accepterat av mottagaren, giltighetsfönstret är uttömt" utan att hävda att en kund läst meddelandet eller avslöjat sina uppgifter.
Välj ägare från det misslyckade stadiet
Köfördröjning hör till applikationen eller den sändande operatören; ett uttryckligt mottagande avslag hör till vägutredningen; ett utgånget eller redan använt resultat hör till tokenpolicyn och applikationstillståndet. Behåll en redigerad korrelationspost och låt den relevanta ägaren definiera ett godkänt omtest.