Quando un'e-mail di accesso all'account arriva in ritardo, gli utenti spesso ne richiedono molte altre. Ciò può creare messaggi duplicati, finestre di validità confuse e carico aggiuntivo sulla coda. Diagnostica il percorso dalla richiesta all'utilizzo corretto prima di incolpare DNS o estendere la durata di ogni token.
Costruisci una sequenza temporale degli eventi redatta
Utilizza un identificatore di correlazione interna per la richiesta di unione accettata, il token creato, il lavoro in coda, il fornitore accettato, la risposta del destinatario e il token riscattato o rifiutato. Non inserire token, reimpostare URL o OTP nei registri di routine. Registra identificatori e categorie di motivi con accesso strettamente limitato a qualsiasi campione di messaggio richiesto per la risoluzione dei problemi.
L'accettazione SMTP significa che in quella fase un server ha accettato la responsabilità; non dimostra il posizionamento della casella di posta o la lettura del messaggio da parte di un essere umano. Mantenere questa distinzione negli strumenti di supporto. RFC 5321.
Guida alla registrazione OWASP supporta la correlazione escludendo i segreti dai registri di routine.
Autenticazione separata dalla validità dell'applicazione
Ispeziona i messaggi controllati finali per le identità del mittente previste e i risultati dell'autenticazione del destinatario attendibile. Una configurazione obsoleta del fornitore può interrompere questo percorso anche mentre le newsletter funzionano. Al contrario, il passaggio dell'autenticazione della posta non può rendere valido un token dell'applicazione scaduto o già utilizzato.
OWASP consiglia token o codici monouso generati in modo sicuro con scadenza adeguata, archiviazione sicura e protezioni contro l'enumerazione degli account e richieste eccessive. La guida per la reimpostazione della password fornisce la base di sicurezza per i flussi di reimpostazione, non una promessa sulla latenza di consegna della posta elettronica. OWASP Guida per la password dimenticata.
I codici consegnati tramite posta elettronica per altri usi di autenticazione richiedono una propria valutazione della sicurezza. Non descrivere il possesso di e-mail come un'autenticazione resistente al phishing e non dare per scontato che una raccomandazione di reimpostazione della password approvi ogni distribuzione OTP. Nell’ambito dei suoi requisiti di identità digitale, NIST proibisce la posta elettronica come autenticatore fuori banda, distinguendo i codici di conferma e ripristino dell’indirizzo da tale divieto. NIST SP 800-63B-4 sezioni 3.1.3 e 3.1.3.1.
Lavorare sul budget di validità
Una timeline ipotetica fissa la creazione del token alle 09:00:00 e la scadenza alle 09:05:00 . L'accettazione del fornitore avviene alle 09:00:10 , l'accettazione del destinatario alle 09:04:40 e l'azione illustrativa dell'utente alle 09:05:20 . Rimangono solo 20 secondi all'accettazione del ricevitore; l'azione avviene 20 secondi dopo la scadenza.
In base a una politica dichiarata secondo cui un token non è valido alla o dopo la sua scadenza, un token altrimenti valido e inutilizzato presentato al secondo 299 rimarrebbe ancora all'interno di questa finestra di cinque minuti, mentre la presentazione ai secondi 300 o 301 no. Un token già riscattato non deve diventare riutilizzabile semplicemente perché rimane del tempo. Questi sono risultati attesi dalla politica inventata, non controlli simbolici eseguiti o una durata universale raccomandata.
La domanda risolvibile è dove sono finiti i 280 secondi tra la creazione e l'accettazione del destinatario. L'accettazione del fornitore al secondo 10 non dimostra che i successivi 270 secondi siano stati trascorsi interamente all'interno di un fornitore; ottenere prove della coda e della risposta prima di assegnare la responsabilità. La visibilità della posta in arrivo rimane sconosciuta. Non è stato testato alcun token reale, account di produzione o consegna.
Riparare la fase fallita
Se l'applicazione è in coda troppo lentamente, dai la priorità al carico di lavoro di accesso all'account ed elimina i ritardi batch evitabili. Se il fornitore segnala errori temporanei, controlla le risposte complete e la gestione dei tentativi supportata. Se il token viene invalidato da una richiesta più recente, rendi comprensibile il comportamento senza rivelare se un account esiste a un richiedente non autenticato.
Utilizza i limiti di velocità e cancella le risposte alle richieste generiche per evitare che i clic ripetuti diventino un flusso di posta. Riconciliare i tentativi con la policy dei token dell'applicazione. Il reinvio cieco di un vecchio messaggio può consegnare un token già non valido, mentre l'emissione di nuovi token illimitati può aumentare il rischio di abuso.
Verifica senza registrare i segreti
Testa gli account controllati approvati nelle destinazioni pertinenti e registra la latenza della fase, l'esito della scadenza e la gestione dei duplicati. Qualsiasi modifica alla scadenza, alla generazione di token o al ripristino dell'account richiede una revisione della sicurezza; l'estensione della durata non sostituisce la correzione delle code.
Chiudi l'incidente con una causa specifica per la fase, una soluzione mirata e un percorso del cliente misurato. Mantieni esplicite le restanti lacune di visibilità. Il supporto dovrebbe essere in grado di spiegare "accettato dal destinatario, periodo di validità esaurito" senza pretendere che un cliente abbia letto il messaggio o esponendo le proprie credenziali.
Scegli il proprietario dalla fase fallimentare
Il ritardo nella coda dipende dall'applicazione o dall'operatore mittente; un esplicito rifiuto di ricezione rientra nell'indagine del percorso; un risultato scaduto o già utilizzato appartiene alla policy dei token e allo stato dell'applicazione. Conservare un record di correlazione redatto e chiedere al proprietario pertinente di definire un nuovo test approvato.