Diciamo che un utente malintenzionato ha la tua password. Accedi e ripristinalo. Se il reset non invalida tutte le sessioni esistenti, l'utente malintenzionato ha ancora accesso, a condizione che non lasci scadere la sessione.

Il reset non ha effettivamente ottenuto nulla in questo scenario.

A seconda di ciò che fa il sito, potrebbero esserci problemi con il fatto di aver effettuato l'accesso con una password che non è più aggiornata. Diciamo che la tua password è utilizzata per sbloccare qualcosa, hai effettuato l'accesso con "password1", ma ora il server ha la tua password salvata come "password2", cosa succede? Questo è ovviamente ipotetico, ma si spera che illustri il punto.

Reindirizzamento alla schermata di accesso credo sia solo una raccomandazione. Non sono sicuro del motivo per cui importa dove si invia l'utente, ma dal punto di vista dell'usabilità ha più senso inviare l'utente a una pagina di accesso anziché alla home page.

Protezione delle sessioni su un account possibilmente compromesso

Non è necessario reindirizzare effettivamente la pagina di accesso se la gestione della sessione al cambio della password avviene in modo sicuro. Cioè, a condizione che tutti gli identificatori di sessione correnti siano invalidati e che la sessione corrente sia collegata a un nuovo identificativo di sessione (solitamente emesso come token in un cookie di autenticazione - il cookie viene inviato solo alla sessione che ha appena modificato la password) allora non c'è il rischio che un utente malintenzionato sia già presente nell'account di rimanere connesso.

Articolo OWASP

La logica dietro l'articolo OWASP è spiegata di seguito. Non c'è nulla di sbagliato nell'aspetto della sicurezza, tuttavia ci sono alcuni problemi di usabilità.

La funzionalità di reimpostazione della password viene spesso utilizzata quando un utente desidera proteggere il proprio account.

Invalidando tutte le sessioni esistenti al ripristino della password, il sistema si sta assicurando che solo la persona con la nuova password possa accedere.

Supponiamo, ad esempio, che un utente malintenzionato che ha ottenuto l'accesso all'account utilizzando la vecchia password abbia effettuato l'accesso. La reimpostazione di tutte le sessioni registrerà l'autore dell'attacco.

Perché disconnettersi dall'attuale utente, ti sento chiedere?

Diciamo che l'attaccante sta cavalcando la sessione dell'utente corrente, ad esempio utilizzando una vulnerabilità risoluzione della sessione . Ciò significa che l'utente malintenzionato ha la stessa sessione dell'utente reale. La reimpostazione della sessione corrente assicurerà anche che nessuno si trovi sull'account a cui non si intende accedere.

Il reindirizzamento alla pagina di accesso nella tua citazione sopra descrive in realtà il fatto che devi disconnettere l'utente dalla sessione corrente e da tutte le sessioni (ma non vi è alcun rischio di fermarti lasciandoli in una nuova sessione con un nuovo identificatore ).

Le altre risposte sono probabilmente più corrette da una prospettiva netsec, ma volevo aggiungere che si assicuri anche che l'utente sia effettivamente in grado di accedere con la nuova password. Ciò rende ovvio se qualcosa va storto, come il browser che carica automaticamente una vecchia password.

Impedisce inoltre agli utenti di utilizzare la reimpostazione della password come accesso. Su uno dei miei account è più facile rispondere alle domande di sicurezza che ricordare la password, poiché devo impostare una password univoca ogni volta che la reimposta e non riesco a ricordarle.

Esiste solo una possibile ragione di sicurezza per inviarti alla pagina di accesso, poiché tutte le vecchie sessioni possono essere invalidate e la sessione attiva corrente ha cambiato la password da automaticamente sostituita:
Rende l'uso della reimpostazione della password per l'accesso più ingombrante, portando così a utilizzarlo meno spesso e quindi a renderlo più sicuro da intercettazioni e divulgazioni accidentali.

C'è anche un motivo di usabilità per che ti manda lì: si assicura che tu possa effettivamente usare la nuova password, e ogni cache password del browser venga aggiornata.

Se agli utenti è consentito avere il browser in cui memorizzare le proprie password, reindirizzare l'utente alla pagina di accesso consentirà al browser di acquisire la nuova password in quella pagina. Altrimenti, la volta successiva che l'utente accede al browser, "utile" precompilerà il campo della password con la vecchia password: un'azione che potrebbe causare confusione se l'utente non si rende conto di cosa sta succedendo.

È molto semplice se teniamo in considerazione le contromisure di sicurezza. In realtà invaliderà tutte le tue sessioni attive, così come il dispositivo di ladro, che ha creato il problema.

Oltre a fornire un meccanismo semplice per stabilire una nuova sessione valida, verificare che la nuova password funzioni e disconnettere le sessioni correnti, c'è anche il vantaggio di avere l'utente di inserire la password una terza volta, semplificando da ricordare.

Oltre a molti degli altri punti qui presentati, ci sono dei vantaggi nel limitare il meccanismo di creazione della sessione a un solo punto di accesso da una prospettiva di mantenimento / indurimento / controllo.

Un utente che reimposta la propria password nello stato bloccato non deve essere necessariamente considerato come un utente che ha effettuato il login, anche dopo aver superato qualsiasi prova di recupero dei circuiti di identità altrimenti avrà una sequenza aggiuntiva da verificare durante l'audit / test delle penne.