Supponiamo che un utente malintenzionato abbia la tua password. Accedi e reimposta. Se il ripristino non invalida tutte le sessioni esistenti, l'attaccante ha ancora accesso, purché non lasci scadere la sessione.

Il ripristino non ha effettivamente ottenuto nulla in questo scenario.

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

Il reindirizzamento alla schermata di accesso immagino sia solo un consiglio. Non sono sicuro del motivo per cui sia importante dove mandi l'utente, ma dal punto di vista dell'usabilità ha più senso indirizzare l'utente a una pagina di accesso piuttosto che alla home page.

Protezione delle sessioni su account potenzialmente compromessi

Non è necessario reindirizzare effettivamente alla pagina di accesso se la gestione della sessione al momento della modifica della password viene eseguita in modo sicuro. Cioè, fintanto che tutti gli identificatori di sessione correnti sono invalidati e la sessione corrente è allegata a un nuovo identificatore di sessione (solitamente emesso come token in un cookie di autenticazione - il cookie viene inviato solo alla sessione che ha appena cambiato la password), allora lì non c'è il rischio che un utente malintenzionato che è già nell'account rimanga connesso.

Articolo OWASP

La logica alla base dell'articolo OWASP è spiegata di seguito. Non c'è niente 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 tutto sessioni esistenti al momento della reimpostazione della password, il sistema si assicura 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 sia loggato . Il ripristino di tutte le sessioni disconnetterà l'attaccante.

Perché disconnettere l'utente corrente, ho sentito che lo chiedi?

Bene, dì che l'attaccante sta cavalcando la sessione dell'utente corrente, ad esempio utilizzando una vulnerabilità di riparazione della sessione. Ciò significa che l'attaccante ha la stessa sessione dell'utente reale. La reimpostazione della sessione corrente assicurerà inoltre che sull'account non sia presente nessuno che non sia destinato ad avere accesso.

Il reindirizzamento alla pagina di accesso nel preventivo sopra descrive in realtà il fatto che è necessario disconnettere l'utente della sessione corrente e di tutte le sessioni (ma non vi è alcun rischio di impedirti di rilasciarle in una nuova sessione con un nuovo identificatore).

Le altre risposte sono probabilmente più corrette dal punto di vista di netsec, ma volevo aggiungere che puoi anche assicurarti che l'utente sia effettivamente in grado di accedere con la nuova password. Questo rende ovvio se qualcosa sta andando storto, come il browser che riempie automaticamente una vecchia password.

Impedisce inoltre agli utenti di utilizzare la reimpostazione della password come login. 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 reimposto e non riesco a ricordarle.

C'è solo un possibile motivo correlato alla sicurezza per inviarti alla pagina di accesso, poiché tutte le vecchie sessioni possono essere invalidate e la tua sessione attiva corrente da cui hai cambiato la password viene sostituita automaticamente:
Rende più complicato l'uso della reimpostazione della password per l'accesso, portandoti così a usarlo meno spesso e proteggendolo così da intercettazioni e divulgazioni accidentali.

C'è anche un motivo di usabilità per inviarti lì: si assicura che tu possa effettivamente utilizzare la nuova password e qualsiasi cache delle password nel browser viene aggiornata.

Se gli utenti possono fare in modo che il browser memorizzi le proprie password, reindirizzare l'utente alla pagina di accesso consentirà al browser di acquisire la nuova password in quella pagina. Altrimenti, la prossima volta che l'utente accede al browser pre-riempirà "utilmente" il campo della password con la vecchia password, un'azione che potrebbe creare 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 del ladro, che ha creato il problema.

Oltre a fornire un semplice meccanismo per stabilire una nuova sessione valida, verificare che la nuova password funzioni e disconnettersi dalle sessioni correnti, c'è anche il vantaggio aggiuntivo di avere il tuo utente che inserisce la password una terza volta, rendendolo più facile da ricordare.

Oltre a molti degli altri punti qui esposti, ci sono vantaggi nel limitare il meccanismo di creazione della sessione a un solo punto di ingresso da una prospettiva di manutenibilità / rafforzamento / controllo.

Un utente che reimposta la propria password nel lo stato di blocco non deve essere necessariamente trattato come un utente connesso anche dopo aver saltato attraverso qualsiasi prova di ripristino dell'identità che hai, altrimenti hai una sequenza aggiuntiva da verificare quando esegui il test di controllo / penna.

quando accedi di nuovo subito dopo la reimpostazione della password

a) è più probabile che tu ricordi la password 3 secondi dopo, rispetto a 3 giorni dopo.

b) il tuo browser può quindi chiedere all'utente se desidera aggiornare la password salvata con quella nuova, quindi il browser la ricorderà nella pagina di accesso.