Non ho familiarità con questo quadro esatto, quindi questo è un consiglio di sicurezza generico, ma: il modo corretto di gestire i flussi di reimpostazione della password (con un token contenuto in un URL che l'utente riceve via e-mail, quindi fa clic), è per il token stesso da utilizzare per cercare l'utente. Non è necessario alcun altro modo per identificare l'utente (il token è univoco per ogni utente e, naturalmente, per ogni tentativo di reimpostazione della password, ovviamente).
È una cattiva idea molto avere persino un altro modo per identificare l'utente che sta reimpostando la propria password, perché se lo fai, ti apri il rischio che un utente malintenzionato entri in indirizzo email di qualcun altro (o ID utente, nome o altro) e reimpostazione della password dell'altra persona. Per evitare ciò, è necessario confermare che il token del collegamento è il token di reimpostazione della password corrente per l'utente indicato e, se è possibile farlo, è possibile identificare l'utente direttamente dal token e non è necessario che l'utente fornire l'identità. Passare l'identità nell'URL non è più sicuro; un utente malintenzionato può modificare l'URL prima di caricare la pagina web così come può mentire sulla propria identità in un modulo Web.
Se non c'è modo per il server di cercare un utente dal proprio token di reimpostazione della password, quindi francamente si tratta di un bug incredibilmente stupido e dovrebbe essere segnalato e / o corretto (se open source) immediatamente. Un bug del genere mi farebbe seriamente mettere in discussione la qualità dell'intero codebase di autenticazione.
Modifica
La possibilità che il requisito esista per fornire ulteriore sicurezza mi è venuta in mente, ma inizialmente non l'ho incluso nella risposta in quanto sembrava improbabile. Dovrebbe essere completamente impossibile forzare le token; devono essere almeno 128 bit di stringa casuale generata in modo sicuro, con una durata misurata in minuti (al massimo una singola cifra al massimo) prima dell'uso e scadono immediatamente dopo l'uso. Ciò lascia solo un modo per consentire a un utente malintenzionato di acquisire il token prima che venga utilizzato, e ci sono delle attenuazioni a tutti quei vettori:
- L'attaccante ha catturato gli URL della vittima (magari in un registro proxy o simile) e riesce a utilizzare il token per reimpostare la password della vittima prima che la vittima possa farlo da sé. Le probabilità che ciò accada in una situazione in cui l'hacker non è in grado di determinare l'indirizzo e-mail della vittima sono piuttosto ridotte (in quanto implica che l'autore dell'attacco sia in grado di visualizzare il testo in chiaro del traffico HTTPS della vittima).
- La vittima fa clic sul collegamento, quindi si allontana dal computer prima di completare la reimpostazione della password, senza bloccarla e l'utente malintenzionato si siede davanti alla macchina. Ciò implica sia un livello di "utente che è incredibilmente sciocco" (e tu sai cosa dicono di fare qualcosa di a prova di idiota), e l'attaccante potrebbe semplicemente andare a cercare l'indirizzo email della vittima (sono seduti al computer dove la vittima ha appena cliccato sul link!) nel caso in cui l'aggressore non lo sapesse già. Questo attacco è più adeguatamente mitigato rendendo la stessa pagina di reimpostazione della password una durata molto breve (non dovrebbero essere necessari più di cinque minuti per immettere una nuova password, massimo, anche supponendo che l'utente sia disabilitato e debba utilizzare un sistema di input veramente lento ).
C'è un argomento per, in situazioni estremamente paranoiche, proteggere dal primo caso accettando il costo della seccatura degli utenti e assumendosi il rischio di un'implementazione insicura. Per la maggior parte, sembra un netto netto negativo nell'utilità. Il secondo caso non fa nemmeno menzione del fatto che la "protezione" del richiedere l'identità è banalmente evitata. A meno che non ci sia qualche altro scenario che mi manca, questo fornisce un beneficio trascurabile.