No, non c'è una necessità schiacciante di token di reimpostazione della password hash, purché siano limitati nel tempo e monouso. Ci sono alcuni vantaggi per i token di reimpostazione dell'hash, ma il vantaggio è inferiore rispetto alle password, quindi non considererei assolutamente necessario l'hashing dei token di ripristino.
In genere, i token di reimpostazione della password sono limitati nel tempo. Ad esempio, potrebbero essere buoni solo per un'ora e scadono dopo. Inoltre, normalmente i token di reimpostazione della password sono limitati in modo che possano essere utilizzati solo una volta e, dopo essere stati utilizzati, vengono revocati. Questa è una buona pratica e dovresti assolutamente farlo.
Se si esegue questa operazione, non è necessario eseguire l'hash dei token di reimpostazione della password quando vengono archiviati nel database. Ricordiamo il modello di minaccia con cui l'hashing è progettato per difendersi: è progettato per mitigare le violazioni di database una tantum. In altre parole, assumiamo che l'avversario trovi una vulnerabilità che gli consente di scaricare il database in un singolo punto nel tempo. (Forse una vulnerabilità di SQL injection, o qualcosa del genere.) Vogliamo limitare il più possibile il danno, se questo accade.
Per le password, è importante eliminarle. In caso contrario, accadono due cose brutte: (i) una singola violazione del database compromette la password di ogni utente, consentendo all'utente malintenzionato di accedere all'account di ogni utente sul tuo sito; e (ii) poiché gli utenti spesso riutilizzano le loro password su altri siti, ciò potrebbe consentire all'utente malintenzionato di accedere agli account dei suoi utenti su altri siti. Se fai l'hash, una violazione del database è ancora negativa, ma è molto meno grave.
Per i token di reimpostazione della password, nessuno di questi è vero. Supponiamo che tu non abbia hash i token di reimpostazione della password. Quindi una singola violazione del database rivelerà solo il set di token di reset attivi al momento della violazione. Potresti avere milioni di utenti sul tuo sito, ma solo pochi token di reimpostazione attivi su quel tiem, quindi solo pochi utenti hanno i loro account esposti. È molto, molto meno serio.
Inoltre, i token di reimpostazione della password vengono scelti in modo casuale, non dall'utente. Di conseguenza, non vengono riutilizzati su altri siti e la compromissione di un token di ripristino per il sito x.com non comporta alcun rischio per l'account dell'utente su altri siti (ad esempio y.com ). Pertanto, il secondo motivo per cui le password utente hash non si applicano per reimpostare i token, sia.
Vale la pena ricordare che esiste uno scenario in cui è possibile sfruttare i token di reimpostazione della password non modificati: se l'utente malintenzionato riesce a ottenere l'accesso in lettura al database, l'utente malintenzionato può richiedere una reimpostazione della password per alcuni utenti ( alice ), leggere il database per osservare il token di reimpostazione della password di alice , quindi usarlo per cambiare la password di alice e ottenere l'accesso al suo account. Tuttavia, ci sono alcuni fattori attenuanti qui. L'attaccante deve farlo in tempo reale, quindi la finestra temporale dell'attaccante è limitata. L'attacco è molto rumoroso e rilevabile, dal momento che un'email viene inviata a alice . Se l'aggressore tentasse di assumere il controllo di molti account in questo modo, la violazione verrebbe probabilmente notata molto rapidamente (gli utenti contatterebbero gli amministratori del sito, che si spera possano indagare). Questo è un deterrente per gli aggressori che cercano di montare un simile attacco contro molti utenti. Non ferma un attacco mirato in cui l'attaccante vuole solo influenzare alcuni utenti, ma rende meno probabile che un utente malintenzionato sia in grado di accedere agli account di tutti (come sarebbe accaduto con una password non modificata). Quindi, i token di reset senza interruzione sono meno preoccupanti delle password non trattate.
Non fraintendermi. Vi sono alcuni vantaggi per i token di reimpostazione della password di hashing. Tuttavia, richiede anche un certo sforzo per scrivere il codice per cancellare i token di reset. Poiché il vantaggio in termini di sicurezza è limitato, dal punto di vista della gestione del rischio non sarebbe ridicolo decidere di memorizzare i token di ripristino senza hash.
Non sto dicendo "non hash resettare i token". Se hai la possibilità di cancellarli, vai avanti: otterrai un vantaggio di sicurezza. Allo stesso tempo, per mettere questo in prospettiva, questa probabilmente non è la caratteristica di sicurezza più importante da implementare. Probabilmente puoi trovare molti altri modi per rafforzare la sicurezza del tuo sito che offrirà maggiori vantaggi.
Bottom line: i token di reset della password di hashing hanno qualche vantaggio, ma sono limitati. Non lo considero una funzionalità di sicurezza indispensabile.