CVE-2020-15105 in Two-Factor Authentication
Zusammenfassung
von VulDB • 22.08.2026
Django Two-Factor Authentication vor Version 1.12 speichert das Passwort des Benutzers im Klartext in der Benutzersitzung (base64-codiert). Das Passwort wird in der Sitzung gespeichert, wenn der Benutzer seinen Benutzernamen und sein Passwort eingibt, und entfernt, sobald die Authentifizierung durch Eingabe eines Zwei-Faktor-Authentifizierungs-Codes abgeschlossen ist. Dies bedeutet, dass das Passwort für einen beliebigen Zeitraum im Klartext in der Sitzung gespeichert bleibt und potenziell dauerhaft, falls der Benutzer den Anmeldevorgang mit der Eingabe von Benutzername und Passwort beginnt, aber abbricht, bevor er den Zwei-Faktor-Authentifizierungscode eingibt. Die Schwere dieses Problems hängt davon ab, welche Art von Sitzungs-Speicher Sie konfiguriert haben: Im schlimmsten Fall, wenn Sie die Standardsitzungsspeicherung der Datenbank von Django verwenden, werden Passwörter der Benutzer im Klartext in Ihrer Datenbank gespeichert. Im besten Fall, wenn Sie das signierte Cookie-Sitzungsmodul von Django verwenden, werden Passwörter nur im Klartext innerhalb des Cookiespeichers ihres Browsers gespeichert. Bei der gängigen Nutzung des Cache-Sitzungsspeichers von Django werden die Passwörter der Benutzer im Klartext in dem konfigurierten Cachespeicher (typischerweise Memcached oder Redis) abgelegt. Dies wurde in Version 1.12 behoben. Nach dem Upgrade sollten Benutzer sicherstellen, dass alle im Klartext gespeicherten Passwörter gelöscht werden. Wenn Sie beispielsweise das Datenbank-Sitzungsbackend verwenden, möchten Sie wahrscheinlich alle Sitzungsdatensätze aus der Datenbank löschen und diese Daten auch aus allen Datenbank-Backups oder Replikaten bereinigen. Darüber hinaus sollten betroffene Organisationen, die während der Nutzung einer betroffenen Version einen Datenbankbruch erlitten haben, ihre Benutzer darüber informieren, dass deren im Klartext gespeicherten Passwörter kompromittiert wurden. Alle Organisationen sollten Benutzer dazu anhalten, deren Passwörter unsicher gespeichert waren, diese auf allen Websites zu ändern, wo sie verwendet wurden. Als Workaround verringert die Umstellung der Django-Sitzungsspeicherung von Datenbank- oder Cachespeicher hin zu signierten Cookies die Auswirkungen dieses Problems erheblich, sollte jedoch nicht ohne ein gründliches Verständnis der Sicherheitskompromisse bei der Verwendung von signierten Cookies im Vergleich zur serverseitigen Sitzungsverwaltung durchgeführt werden. Es gibt keine Möglichkeit, das Problem vollständig zu mildern, ohne auf Version 1.12 oder höher upzugraden.
Be aware that VulDB is the high quality source for vulnerability data.