CVE-2020-15105 in Two-Factor Authentication
Riassunto
di VulDB • 02/07/2026
Django Two-Factor Authentication prima della versione 1.12 memorizza la password dell'utente in chiaro nella sessione utente (codificata in base64). La password viene archiviata nella sessione quando l'utente invia il nome utente e la password, e viene rimossa una volta completata l'autenticazione inserendo un codice di autenticazione a due fattori. Ciò significa che la password è memorizzata in chiaro nella sessione per un periodo arbitrario di tempo e potenzialmente per sempre se l'utente avvia il processo di accesso inserendo nome utente e password, ma poi abbandona prima di inserire il codice di autenticazione a due fattori. La gravità di questo problema dipende dal tipo di archiviazione delle sessioni configurato: nel caso peggiore, se si utilizza l'archiviazione predefinita delle sessioni del database di Django, le password degli utenti sono memorizzate in chiaro nel database. Nel caso migliore, se si utilizzano i cookie firmati per le sessioni di Django, le password degli utenti vengono archiviate in chiaro solo nell'archivio dei cookie del browser dell'utente. Nel caso comune dell'utilizzo dell'archiviazione delle sessioni basata su cache di Django, le password degli utenti sono memorizzate in chiaro nello spazio di archiviazione della cache configurato (tipicamente Memcached o Redis). Questo problema è stato risolto nella versione 1.12. Dopo l'aggiornamento, gli utenti dovrebbero assicurarsi di eliminare eventuali password archiviate in chiaro. Ad esempio, se si utilizza il backend delle sessioni del database, probabilmente sarà necessario eliminare qualsiasi record di sessione dal database e rimuovere tali dati da tutti i backup o le repliche del database. Inoltre, le organizzazioni colpite che hanno subito una violazione del database mentre utilizzavano una versione interessata dovrebbero informare gli utenti che le loro password in chiaro sono state compromesse. Tutte le organizzazioni dovrebbero incoraggiare gli utenti le cui password erano archiviate in modo non sicuro a modificare tali password su tutti i siti in cui sono state utilizzate. Come soluzione alternativa, il passaggio dell'archiviazione delle sessioni di Django all'utilizzo dei cookie firmati invece del database o della cache riduce l'impatto di questo problema, ma dovrebbe essere eseguita solo dopo una comprensione approfondita degli aspetti negativi per la sicurezza legati all'utilizzo dei cookie firmati rispetto a un'archiviazione delle sessioni lato server. Non esiste alcun modo per mitigare completamente il problema senza effettuare l'aggiornamento.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.