Does that seem OK?

Sì, supponendo che le email siano la forma principale di autenticazione del tuo sito.

Anything changed over the years where this approach is no longer recommended?

Non che io sappia.

Ecco alcuni punti che devi prendere in considerazione.

Che tipo di feedback fornirai all'utente

Quando l'email non esiste, cosa dirai e cosa fare?

• Se visualizzi un messaggio del tipo "Mi dispiace, questa email non esiste", stai effettivamente divulgando informazioni su chi è o non è presente nel tuo database.
• Quindi, invece, puoi visualizzare un messaggio sulla falsariga di "Se questa e-mail corrisponde a un account utente, otterrai ulteriori istruzioni". Questo è più sicuro, ma potrebbe confondere i tuoi utenti ("perché non ho ricevuto l'e-mail?").
• Una terza opzione è quella di sempre inviare un'e-mail, solo con un contenuto diverso se l'e-mail non era nel tuo database. Questo apre il tuo modulo per abuso, dato che chiunque potrebbe digitare l'email di qualcun altro, e le tue e-mail verrebbero eventualmente inviate tramite spam.

Se il tuo sistema utilizza il nome utente, potrebbe essere meglio chiedere il nome utente, non l'indirizzo email. Invia l'email di recupero all'indirizzo email associato all'account, senza rivelarlo all'utente.

Come proteggi il processo contro gli abusi

• È facile vedere come qualcuno può utilizzare questo modulo per generare e-mail e quindi utilizzare l'ingegneria sociale per indurre un utente a fare clic sul link (o peggio, inoltrare l'e-mail). Pertanto, dovresti renderlo molto chiaro nella tua email.
• Devi proteggere questo modulo contro la forza bruta in un modo o nell'altro. Alcuni esempi: non più di una richiesta attiva per account (non inviare nuovamente email fino alla scadenza precedente), numero limitato di tentativi per indirizzo IP, limitazione, CAPTCHA, ecc.

Il token

Il token è in realtà una One Time Password per un account utente.

• Il token dovrebbe essere random e imprevedibile e archiviato nel database con un'associazione con l'ID utente corrispondente e il timestamp. Non hai bisogno di MD5, né hai bisogno di codificare nulla nel token. Esempio in PHP, per un token di 32 caratteri: bin2hex(openssl_random_pseudo_bytes(16));
• Il token deve avere una vita breve. 1 ora sembra un po 'lungo per me, presumo che se hai dimenticato la password, vuoi recuperarla ora , quindi 30 minuti è probabilmente molto, ma onestamente questo dipende da voi. Il punto è limitare la durata del token.
• Devi disattivare il token non appena è stato utilizzato .
• Non dovresti avere più di un token attivo per utente in un dato momento. Da un punto di vista del database relazionale, è più semplice applicare questa regola quando si utilizza un campo (nullable) nella tabella users , piuttosto che una tabella separata.
• Non sono sicuro dell'utilità dell'hashing del token di ripristino. Dal tuo database, il rischio è già mitigato dal breve tempo di vita e dall'utilizzo unico. Il vero rischio è nel trasporto, poiché vengono inviati tramite e-mail (non sicuri), quindi possono essere quindi compromessi. Ma perché no.

Non so se questo è un approccio generale o se è solo il mio modo personale / idea per un tale problema, ma farei quanto segue.

Prendi l'IP del client, crittalo con qualsiasi algoritmo che ti piace, ma il risultato nel link come token e inseriscici un timestamp.

Quindi il link è valido solo per l'IP del client e per un dato periodo.

Ora anche un uomo nell'attacco centrale non è in grado di dirottare il token di reset.

Potresti anche richiedere l'indirizzo MAC dell'utente, ma nella mia mente questo è principalmente un eccesso.

Questo è il mio approccio personale per ottenere un token di ripristino moderno salva.

Cercherò sicuramente di scoprire gli ultimi e più grandi algoritmi di crittografia. C'è un sacco di dibattito su quale funziona meglio, ma in generale ho scoperto che, tra algoritmi all'avanguardia, i vantaggi tra uno o l'altro sono trascurabili. Detto questo, guarderei sicuramente alle alternative a MD5 come SHA256, SHA512, RipeMD o WHIRLPOOL. È sempre una buona idea fare la tua ricerca e riaffermare che i tuoi metodi di crittografia non sono stati sottratti.

Inoltre, non ho visto nulla nella tua domanda che includesse SALTing. Questo è sicuramente qualcosa che potresti prendere in considerazione per implementare quella sicurezza extra per gli utenti che potrebbero implementare password troppo semplici per gli hacker per craccare usando attacchi di dizionario o tabelle hash.

Un'ultima cosa (e presumo che tu l'abbia considerato); Mi assicurerei che l'e-mail di recupero che inseriscono nel sistema di Forgot-my-Password corrisponda effettivamente all'e-mail che hai sul file per quell'utente ... e potrei anche includere una domanda di sicurezza solo per essere al sicuro.