Perché non inviare una password di ripristino in testo normale? [duplicare]

If a user follows a link and sets a password, or gets a password, logs on, and changes it, the danger seems the same.

Sulla base di tutti i post che ho visto, penso che il problema sia con "e lo cambi". Nessuna delle e-mail che ho visto indica che la password è temporanea e dovrà essere cambiata. Senza volermi preoccupare di creare personalmente un gruppo di account, sarei prudente e suppongo che, se l'e-mail non dice che dovrai cambiare la password, il sito non ti costringerà a modificarlo dopo aver effettuato l'accesso.

Hai ragione sul fatto che non esiste una vera differenza tra una password temporanea e un link di ripristino se la password ha abbastanza entropia . Come menzionato nei commenti, se la password è troppo corta e l'utente attende un po 'di tempo prima di accedere, potrebbe essere suscettibile alla forza bruta. Poiché i campi delle password dovrebbero consentire di incollare comunque, una password temporanea alfanumerica di 20 caratteri sarebbe perfettamente a posto. Sia il link di reset che la password temporanea potrebbero essere implementati in modo quasi identico, è proprio la differenza tra un POST e un GET.

Il motivo per cui inviare agli utenti le loro password in chiaro di corrente è brutto in quanto "le password devono essere memorizzate in modo che nessuno sul lato server debba mai essere in grado di recuperare la password in chiaro di un utente una volta inserita "(che significa anche root). Il motivo per cui le password sono hash in primo luogo è proprio in modo che l'unica persona che può conoscere la password sia l'utente che l'ha inserita. Questo è l'unico modo per garantire che l'utente non possa ripudiare le azioni intraprese sulla base del fatto che qualcun altro conosce la propria password.

(Per ulteriori informazioni storiche su come funziona l'hashing della password e perché è importante, vedere la mia risposta a Perché l'hash MD5 parte da $ 1 $ e SHA-512 da $ 6 $? Isn ' t debolezza di per sé? )

Inviando agli utenti una nuova password temporanea aggira questo problema, ma crea almeno altri due problemi, come menzionato da Troy Hunt sul suo blog link (riferimento all'articolo 9 delle FAQ degli sviluppatori sul sito plaintextoffenders: link , che è stato menzionato nei commenti sulla domanda stessa):

1. l'utente viene immediatamente bloccato dal proprio account con la normale password, che se non fosse quella che si aspetta di reimpostare la propria password crea un attacco Denial of Service (DOS) immediato e
2. la pagina di accesso in cui il sito si aspetta di ricevere la password temporanea non ha modo di sapere che è temporanea e, se non implementata correttamente, la password temporanea potrebbe rimanere più a lungo accettabile in questo contesto.

Per evitare questi problemi, la pagina di destinazione della reimpostazione della password è separata dal normale processo di accesso, ha un valore segreto che può essere applicato con un https: URL e non annulla la password dimenticata fino a quando la proprietà dell'account non è stata ristabilito dallo scambio di questo valore con l'utente via email.