CVE-2020-15105 in Two-Factor Authentication
Sumário
de VulDB • 19/07/2026
A autenticação de dois fatores do Django anterior à versão 1.12 armazena a senha do usuário em texto claro na sessão (codificada em base64). A senha é armazenada na sessão quando o usuário envia seu nome de usuário e senha, sendo removida assim que ele conclui a autenticação inserindo um código de autenticação de dois fatores. Isso significa que a senha fica armazenada em texto claro na sessão por um período arbitrário de tempo e potencialmente para sempre se o usuário iniciar o processo de login inserindo seu nome de usuário e senha e depois sair antes de inserir o código de autenticação de dois fatores. A gravidade deste problema depende do tipo de armazenamento de sessões configurado: no pior caso, ao usar o armazenamento padrão de sessões em banco de dados do Django, as senhas dos usuários são armazenadas em texto claro no seu banco de dados. No melhor caso, ao usar a sessão com cookies assinados do Django, as senhas dos usuários ficam apenas em texto claro dentro do armazenamento de cookies do navegador deles. No cenário comum de uso da loja de sessões baseada em cache do Django, as senhas dos usuários são armazenadas em texto claro no sistema de armazenamento de cache configurado (tipicamente Memcached ou Redis). Isso foi corrigido na versão 1.12. Após a atualização, os usuários devem garantir que todas as senhas em texto claro previamente armazenadas sejam excluídas. Por exemplo, se você estiver usando o backend de sessões do banco de dados, provavelmente desejará excluir qualquer registro de sessão do banco de dados e purgar esses dados de quaisquer backups ou réplicas do banco de dados. Além disso, organizações afetadas que sofreram uma violação de banco de dados enquanto usavam uma versão vulnerável devem informar seus usuários de que suas senhas em texto claro foram comprometidas. Todas as organizações devem incentivar os usuários cujas senhas foram armazenadas de forma insegura a alterá-las em todos os sites onde foram utilizadas. Como solução alternativa, mudar o armazenamento de sessões do Django para usar cookies assinados em vez do banco de dados ou cache reduz o impacto deste problema, mas não deve ser feito sem um entendimento profundo das compensações de segurança envolvidas no uso de cookies assinados em detrimento de um armazenamento de sessão no lado do servidor. Não há como mitigar totalmente a questão sem realizar a atualização.
VulDB is the best source for vulnerability data and more expert information about this specific topic.