Troy Hunt evidenzia alcuni punti eccellenti nel suo articolo, Tutto quello che avresti sempre voluto sapere sulla creazione di una funzione di reimpostazione sicura della password . Gli estratti più rilevanti sono:
[T] qui ci sono due approcci comuni:
- Genera una nuova password sul server e inviala tramite e-mail
- Invia un URL univoco che faciliterà un processo di reimpostazione
Nonostante molte indicazioni contrarie, il primo punto non è proprio dove vogliamo essere. Il problema nel fare questo è che significa che una password persistente - una con cui puoi tornare indietro e usare in qualsiasi momento - è stata inviata su un canale non sicuro e risiede nella tua casella di posta.
...
Ma c'è un altro grosso problema con il primo approccio in quanto rende semplice il blocco dannoso di un account. Se conosco l'indirizzo e-mail di qualcuno che possiede un account su un sito Web, posso bloccarlo ogni volta che per favore semplicemente reimpostando la password; è un attacco denial of service servito su un piatto d'argento! Questo è il motivo per cui un ripristino è qualcosa che dovrebbe avvenire solo dopo aver verificato con successo il diritto del richiedente di farlo.
Quando parliamo di un URL di ripristino, stiamo parlando di un indirizzo del sito Web che è unico per questa specifica istanza del processo di ripristino.
...
Quello che vogliamo fare è creare un token univoco che può essere inviato in un'e-mail come parte dell'URL di reimpostazione, quindi abbinato a un record sul server accanto all'account dell'utente, confermando che il proprietario dell'account e-mail è effettivamente quello che tenta di ripristinare parola d'ordine. Ad esempio, il token può essere "3ce7854015cd38c862cb9e14a1ae552b" ed è memorizzato in una tabella accanto all'ID dell'utente che esegue il ripristino e al momento in cui il token è stato generato (ne parleremo più in un momento). Quando l'e-mail viene inviata, contiene un URL come "Reimposta /? Id = 3ce7854015cd38c862cb9e14a1ae552b" e quando l'utente carica questo, la pagina verifica l'esistenza del token e quindi conferma l'identità dell'utente e consente alla password di essere cambiato.
...
L'altra cosa che vogliamo fare con un URL di reimpostazione è limitare il token in modo che il processo di reimpostazione debba essere completato entro una certa durata, ad esempio entro un'ora.
...
Infine, vogliamo garantire che si tratti di un processo una tantum. Una volta completato il processo di ripristino, il token deve essere eliminato in modo che l'URL di ripristino non sia più funzionale. Come nel punto precedente, ciò per garantire che un utente malintenzionato abbia una finestra molto limitata in cui può abusare dell'URL di reimpostazione. Inoltre, ovviamente, il token non è più necessario se il processo di ripristino è stato completato correttamente.
Fa molti altri aspetti positivi nell'evitare perdite di informazioni, CAPTCHA, autenticazione a due fattori e, naturalmente, le migliori pratiche di base come l'hash della password. Penso che sia importante notare che non sono d'accordo con Troia sull'utilità delle domande di sicurezza, preferendo lo scetticismo di Bruce Schneier sulla pratica :
Il punto di tutte queste domande è lo stesso: una password di backup. Se si dimentica la password, la domanda segreta può verificare la propria identità in modo da poter scegliere un'altra password o avere il sito e-mail la password corrente a voi. È un'ottima idea dal punto di vista del servizio clienti - è meno probabile che un utente dimentichi il nome del suo primo animale domestico rispetto a una password casuale - ma è terribile per la sicurezza. La risposta alla domanda segreta è molto più facile da indovinare di una buona password e le informazioni sono molto più pubbliche.