In più sistemi che ho creato / supportato Ho visto che la gestione utenti effettua le seguenti operazioni per la reimpostazione della password: generato un token di reimpostazione della password tramite un metodo di hashing e invia tramite e-mail il collegamento con token all'utente. Di solito ci sono bit di informazione inclusi in questi token - ID utente, timbro di sicurezza dell'utente, data, nome del server o chiave del computer (ora sto andando con il framework ASP.Net Identity). Quando l'utente segue il collegamento con token, framework segue lo stesso processo per ricostruire il token e confronta il token con quello fornito dall'utente. Se i token corrispondono, consenti il ripristino della password.
Molte parti del token relative alla macchina del tempo cambiano dal momento della generazione di token al momento in cui l'utente utilizza quel token. Cioè IIS si riavvia e in alcuni casi questo può invalidare il token. Quando l'applicazione web è distribuita su più server (ad es. Web-farm), le probabilità che questo token sia non valido sono più elevate (cioè le chiavi della macchina non sono sincronizzate tra macchine, ecc.).
Ora sto considerando uno scenario in cui memorizzo il token generato nel database, aggiungo un timestamp di generazione. E quando l'utente torna con il token, io non ri-generare il token, ma piuttosto confrontare il token memorizzato, convalidare il timestamp e consentire / disabilitare il reset della password.
Dato che il token ora diventa una password (anche se limitata nel tempo), per una buona misura posso considerarlo come password e solo archivio hash.
Non riesco a pensare a difetti in questo scenario, ma sono sicuro che ce ne siano alcuni. Data l'implementazione di questo scenario è solido, quali altri problemi potrebbero sorgere dall'archiviazione dei token?