I link di verifica delle e-mail dovrebbero essere "limitati nel tempo" dopo la registrazione dell'utente?

Un limite di tempo per un collegamento di verifica è una piccola parte del modello di sicurezza generale per il tuo sistema. Il principale vantaggio in termini di rischio è che se il collegamento viene compromesso, lo stesso collegamento di verifica non può essere utilizzato in futuro (se l'utente non è mai riuscito a utilizzare il collegamento di verifica una tantum). Il collegamento potrebbe essere compromesso da una futura modifica della posta elettronica dell'utente, i risultati vengono valutati dalla scansione della rete e così via. La teoria è che ci vuole del tempo per compromettere il collegamento stesso e poi agire su di esso.

È un rischio di probabilità piuttosto basso, tuttavia, ha senso implementare un limite di tempo.

Tutto si riduce al rischio. Lì è un certo rischio che il link di reset possa essere ottenuto da qualche terza parte, ma quanto ci vorrà è da indovinare. Se la terza parte ha accesso all'account email in qualche modo, non importa in alcun modo, ma c'è la possibilità che l'accesso sia limitato finché l'utente non si allontana dalla sua tastiera senza ricordare di bloccare lo schermo. In realtà, quanto è banale da implementare, perché non vorresti far scadere il link dopo 15/30/60 minuti?

Personalmente, quando sviluppo un'app web con un sistema di reset di accesso, cerco di evitare di usare i collegamenti via email da soli, a meno che I assolutamente non debba farlo. Preferisco di gran lunga un sistema in cui l'utente può reimpostare la propria password sull'applicazione Web stessa, richiedendo loro di inserire 2/3 di informazioni che erano state configurate al momento della creazione dell'account (e quindi eventualmente l'invio tramite e-mail di un collegamento / codice / altro). Di solito le informazioni non possono essere modificate dall'utente, in modo che se l'account viene compromesso, la terza parte non può bloccare l'utente reale dal reimpostare la propria password.

Nessun metodo è a prova di tutto, tutto si riduce a cercare di mitigare i rischi il più possibile senza implementare una sorta di rituale simile ad Aztec che comporta un sacrificio di sangue per reimpostare le password.

Rivolgi la domanda. Perché NON scadono i link di verifica? Se subisce un piccolo sovraccarico, e c'è la possibilità che possa aumentare anche la sicurezza dei tuoi utenti, perché NON? È probabile che il tempo che il tuo sviluppatore impiegherà per implementarlo sia banale, il che è una vittoria rispetto alla (certamente piccola) possibilità di compromesso.

Le cose da fare e da non fare sono di solito abbastanza standard in sicurezza. Se c'è una domanda, pensaci, perché la risposta è probabilmente dalla parte di uno sforzo leggermente maggiore. Sì, devi utilizzare una funzione hash lenta appositamente progettata per l'hashing della password. Sì, devi utilizzare una funzione di derivazione della chiave standard. Sì, dovresti usare HTTPS ovunque. ( Sto guardando tu, Stack Exchange .) No, non puoi scrivere il tuo codice.