Utilizzo dell'hash della password come token di ripristino

Ci sono un paio di svantaggi con questo schema:

1. Come hanno sottolineato altre risposte, questo perde l'hash della password dell'utente. Questo è un problema non perché l'utente legittimo lo ottiene o perché chiunque abbia accesso alla posta elettronica potrebbe possedere l'account (questo è vero anche per i token di reset) ma perché consente a un utente malintenzionato di leggere il email per eseguire un attacco di dizionario sull'hash. È probabile che l'utente imposti la nuova password su qualcosa di molto simile o abbia riutilizzato la stessa password su più siti. La perdita di hash è indesiderabile, anche se correttamente salata & hash. Di conseguenza, se l'e-mail è mai compromessa da un utente malintenzionato, ha un valore per l'utente malintenzionato.
2. Inoltre, come sottolineato, questo rende difficile rigenerare il token o farlo scadere. I token di reimpostazione della password non dovrebbero essere validi a tempo indeterminato nel caso in cui qualcuno acceda a una vecchia copia di e-mail (ad es. Un backup) o lo abbia estratto dal cavo ma non lo utilizza in modo tempestivo. Il tuo "vantaggio" di non scadenza del token è in realtà un inconveniente dal punto di vista della sicurezza. (E marginalmente utile dal punto di vista dell'usabilità.)
3. Nell'e-mail di reset, il token è spesso (sempre?) inserito come parametro della stringa di query. Ciò significa che il token (e l'hash della password degli utenti) verrà archiviato nella cronologia del browser e probabilmente in qualsiasi registro del server web.

Questa è una pessima idea.

Si presume che nessuno tranne l'utente abbia accesso alle proprie e-mail. In tal caso, perché non inviare loro solo la password in chiaro?

In realtà, dovremmo assumere che altri potrebbero avere accesso alle e-mail.

Se ipotizziamo che ci siano diversi problemi con il tuo approccio. Un utente malintenzionato può rompere l'hash e ottenere la password. Ora possono:

• Accedi senza reimpostando la password. Ciò significa che l'utente non sarà a conoscenza del fatto che il suo account è stato preso in consegna.
• Prova la password e le relative varianti in altri servizi (gli utenti riutilizzano le password).

This could have some benefits including no expiration time on the reset email

In realtà non è una funzione, è un bug .

Lo scopo di utilizzare un token di reimpostazione della password non è solo creare un riferimento indiretto o un segreto condiviso per reimpostare le password. È possibile creare funzionalità di sicurezza aggiuntive come la scadenza dei token o limitare l'uso.

Inoltre, non è sicuro inviare gli hash delle password dell'utente. Di solito, qualsiasi utente non autenticato è autorizzato a reimpostare la password su un account. Richiedendo la reimpostazione della password su un account, un avversario sarebbe in grado di eseguire un attacco dizionario / arcobaleno sull'hash della password ottenuta. In sostanza, la sicurezza della password e del sistema è indebolita in modo significativo.

L'utilizzo dell'hash della password memorizzata per la reimpostazione della password può funzionare in modo funzionale per il ripristino della password, poiché è in realtà un segreto condiviso tra server e utente. Non è una soluzione duratura.

Considera una situazione in cui un utente malintenzionato ottiene una copia del database delle password con hash (purtroppo un evento molto comune ). Tale hacker sarebbe quindi in grado di utilizzare queste password con hash per reimpostare la password per tutti i tuoi utenti.

I sistemi che utilizzano i token di reimpostazione della password e archiviano i token hash nel loro database, tale attacco non sarebbe possibile.

sospiro non inventare nuovi schemi password / hash / token.

Il tuo schema avrebbe lo svantaggio di consentire a un utente malintenzionato di ottenere informazioni sul sale che usi per cancellare le password. Fondamentalmente è un attivatore per attacchi con testo normale.

Questo indebolisce sostanzialmente il vantaggio di memorizzare gli hash anziché le password.

Inoltre, questo consentirebbe a qualcuno solo di leggere le tue e-mail per capire sempre quando cambi la tua password.

Inoltre, ciò significa che il token di reimpostazione della password non scade mai. non c'è alcun meccanismo per invalidare semplicemente un token se è stato trapelato. Significa anche che una parte malintenzionata può aspettare finché non si va in vacanza a cambiare la password, in un momento in cui non si può notare (e non si noterà, poiché il token rimane lo stesso finché non si cambia la tua password, quindi non c'è bisogno di una nuova email di ripristino).

Inoltre, questo ha il vantaggio marginale di salvare solo una voce limitata a vita per richiesta di reimpostazione della password in una tabella. Non riesco a vedere il vantaggio di farlo.

Non cercare di essere più intelligente di milioni di persone che costruiscono un'autenticazione allo stato dell'arte.