Se un utente lascia il proprio computer incustodito per alcuni minuti (mentre è connesso), non vogliamo che qualcun altro sia in grado di passare e cambiare rapidamente la propria password. Per prima cosa, questo consentirebbe all'autore dell'attacco di cambiare anche l'indirizzo email associato e ora il legittimo proprietario non recupererà mai il suo account.

Per un'altra cosa, pensa solo al potenziale per l'ufficio scherzi!

La modifica della password è un'operazione abbastanza delicata che ha senso richiedere all'utente di autenticarsi nuovamente. Inoltre, poiché la modifica della password è un'operazione relativamente rara, ciò non presenta molti inconvenienti per gli utenti: cambia solo l'esperienza dell'utente nei rari casi in cui si cambia la password.

A parte la motivazione alla sicurezza espressa da altre risposte (perché la password è molto sensibile e non vogliamo che qualcuno che ottiene un accesso temporaneo, ad esempio un raid all'ora di pranzo, la trasformi in accesso permanente), possono esserci problemi pratici. Ad esempio, nei sistemi in cui sono presenti segreti utente crittografati con password , la vecchia password è necessaria per decrittografare tali dati e ricrittografarli con la nuova password. Questo è esattamente ciò che accade sui sistemi operativi Windows (è una delle grandi differenze con il modello di sicurezza Unix) e può applicarsi anche ad alcuni sistemi basati sul Web (a seconda di ciò che fa il sistema basato sul Web).

Questo è chiamato il principio TOCTOU (Time of Check / Time of Use), il che significa che la garanzia di autenticazione dell'identità dell'utente (cioè l'utente è ancora lo stesso utente che si è autenticato al sistema) è troppo basso per consentirgli di eseguire alcune azioni, come cambiare la password o ridefinire l'identità.

Per assicurarsi che il livello di garanzia dell'autenticazione sia il più alto possibile quando vengono eseguite azioni critiche, il "delta TOCTOU", il tempo tra il controllo delle credenziali e l'utilizzo dei loro privilegi, deve essere il più breve possibile prevenire i problemi affrontati da DW

Per me, questo è un ovvio esempio di un compromesso regolabile tra sicurezza e usabilità.

Un altro motivo secondario per cui potrebbe essere necessaria la vecchia password è quando le password sono sottoposte ad hashing e se vuoi controllare che la nuova password non sia troppo simile a quella vecchia, devi chiedere all'utente, poiché non puoi altrimenti ottenere tali informazioni dalla password con hash.

Come le risposte precedenti hanno suggerito, si tratta di limitare i danni.

Un altro esempio potrebbe essere se la funzione di reimpostazione della password fosse implementata come una chiamata a http: //www.example. com / changepassword.php? newpassword = monkey quindi potrei creare un collegamento del genere, nasconderlo come un tinyurl o qualcosa del genere e inviare a qualcuno che volevo hackerare tale collegamento, e se lo cliccano mentre sono loggati allora io li ho bloccati fuori dal loro account e ne ho preso il controllo.

Se l'applicazione non utilizza il token CSRF (cross site request forgery), la password può essere facilmente aggiornata dall'attaccante semplicemente inviando un collegamento. Inoltre, sarà molto utile se un utente accede alla nostra sessione, quindi non sarà in grado di aggiornare la password.

Stavo cercando uno standard, una linea guida o almeno un termine riconosciuto per la "conferma dell'azione sensibile". Quello che ho trovato è Cheat sheet sull'autenticazione OWASP e la sezione Richiedi nuova autenticazione per funzionalità sensibili. In sintesi, la superficie di attacco è simile a:

• CSRF
• XSS
• dirottamento della sessione compreso l'accesso fisico temporaneo al browser di un utente

Per funzionalità sensibili la richiesta di credenziali correnti per un account (leggere la password corrente nella maggior parte dei casi) mitiga il rischio degli attacchi di cui sopra.

Alcuni prodotti e servizi (vedere di seguito) consentono di definire risorse sensibili e richiedono una nuova autenticazione o un incremento (l'utente deve fornire un fattore di autenticazione aggiuntivo).

Si noti inoltre che l'applicazione a livello di UI non è consigliato. Qui Auth0 ha un esempio di come emettere un token dedicato per una particolare risorsa sensibile con la loro libreria client.

Riferimento:

• Configura Re -autenticazione per risorse sensibili (manuale del prodotto Broadcom SSO)
• autenticazione step-up (documenti Auth0)