Vulnerabilidad en el almacenamiento de contraseña en texto sin cifrar en la sesión del usuario en Django Two-Factor Authentication (CVE-2020-15105)

Django Two-Factor Authentication versiones anteriores a 1.12, almacena la contraseña del usuario en texto sin cifrar en la sesión del usuario (codificada en base64). La contraseña es almacenada en la sesión cuando el usuario introduce su nombre de usuario y contraseña, y se elimina una vez que completa la autenticación al ingresar un código de autenticación de dos factores. Esto quiere decir que la contraseña es almacenada en texto sin cifrar en la sesión durante un período de tiempo arbitrario, y potencialmente para siempre si el usuario comienza el proceso de inicio de sesión ingresando su nombre de usuario y contraseña y luego se sale antes de ingresar su código de autenticación de dos factores. La gravedad de este problema depende del tipo de almacenamiento de sesión que haya configurado: en el peor de los casos, si está usando el almacenamiento de sesión de base de datos predeterminado de Django, las contraseñas de los usuarios son almacenadas en texto sin cifrar en su base de datos. En el mejor de los casos, si está utilizando la sesión de cookies firmada de Django, las contraseñas de los usuarios solo son almacenadas en texto sin cifrar dentro de la tienda de cookies de su navegador. En el caso común de usar el almacén de sesiones de caché de Django, las contraseñas de los usuarios son almacenadas en texto sin cifrar en cualquier almacenamiento de caché que haya configurado (generalmente Memcached o Redis). Esto ha sido corregido en la versión 1.12. Después de la actualización, los usuarios deben asegurarse de eliminar las contraseñas de texto sin cifrar que hayan sido almacenadas. Por ejemplo, si está usando el back-end de sesión de la base de datos, es probable que quiera eliminar cualquier registro de sesión de la base de datos y purgar esos datos de cualquier copia de seguridad o réplica de la base de datos. Adicionalmente, las organizaciones afectadas que han sufrido una violación de la base de datos al usar una versión afectada deben reportar a sus usuarios que sus contraseñas de texto sin cifrar han sido comprometidas. Todas las organizaciones deben exhortar a los usuarios cuyas contraseñas son almacenadas de forma no segura para que cambien estas contraseñas en los sitios donde se utilizaron. Como solución alternativa, cambiar el almacenamiento de sesión de Django para usar cookies firmadas en lugar de la base de datos o caché disminuye el impacto de este problema, pero no se debe hacer sin un conocimiento profundo de las compensaciones de seguridad del uso de cookies firmadas en lugar de un almacenamiento de sesión del lado del servidor. No existe manera de mitigar completamente el problema sin actualizar