Verificação de Hash BCrypt

Para auxiliar nas etapas de mitigação do CVE-2022-xxxx, você pode usar esta ferramenta para verificar se há hashes no seu banco de dados que precisam ser atualizados.

Depois de integrar a aplicação ao seu banco de dados, a ferramenta funciona em duas etapas.

Para demonstrar isso, é usado um aplicativo de exemplo em memória. Nesse aplicativo de exemplo, você pode executar a etapa check, da seguinte forma:

./mvnw spring-boot:run@check

Isso verificará o banco de dados de exemplo em busca de hashes BCrypt que precisam ser atualizados.

Depois, você pode executar a etapa update, da seguinte forma:

./mvnw spring-boot:run@update

Isso tentará atualizar quaisquer hashes vulneráveis que detectar no banco de dados de exemplo.

O aplicativo de exemplo usa a classe VulnerabilityCheck fornecida para verificar e atualizar cada hash de senha.

Configurando Para o Seu Banco de Dados

AVISO: Prossiga com estas etapas somente depois de atualizar seu aplicativo para usar um número de rodadas inferior a 31. A OWASP atualmente recomenda um valor de 10, embora em alguns sistemas de alto desempenho sejam usados valores de até 16.

A ferramenta vem com um exemplo em memória para fins de teste. Você precisará substituí-lo por classes próprias que se integrem aos seus dados.

Para fazer isso, primeiro clone este repositório.

Em seguida, substitua o código no pacote sample por um código que possa acessar os dados de senha no seu aplicativo. Você pode querer escrever um código que verifique as senhas existentes para ver se são vulneráveis. Você vai querer codificar a atualização de quaisquer hashes afetados. Em ambos os casos, você pode usar VulnerabilityCheck para verificar e atualizar um determinado hash.

DICA: Ao escrever o código acima, leve em consideração quantas senhas você precisa atualizar. Lembre-se de levar em conta que a conexão com o banco de dados pode falhar, computadores podem travar, a memória pode acabar e assim por diante. Não é aconselhável, por exemplo, trazer milhões de registros de uma só vez para a memória.

Após atualizar os hashes de senha, você pode agora atualizar para a versão mais recente do Spring Security. Se você estiver usando o recurso de atualização de senha do Spring Security, à medida que os usuários fizerem login, a senha deles será automaticamente re-hash para o novo valor de rodadas configurado.

Perguntas Frequentes

P: Como sei se meus hashes são vulneráveis?

R: Eles são vulneráveis se foram hashados usando a classe BCrypt do Spring Security com um fator de trabalho de 31. Você pode confirmar isso verificando os hashes de senha no seu sistema que são gerenciados pelo Spring Security. Se eles começarem com '{bcrypt}$2a$31', '{bcrypt}$2b$31', '{bcrypt}$2y$31', '{bcrypt}$2$31', '$2a$31', '$2b$31', '$2y$31' ou '$2$31', então essa senha é vulnerável e precisa ser atualizada.

P: Como devo alterar meu aplicativo?

R: A OWASP recomenda um fator de trabalho de 10 para BCrypt. Alguns sistemas de alto desempenho usarão um valor de até 16. Cada sistema é diferente e o BCrypt foi projetado para poder aumentar o fator de trabalho ao longo do tempo conforme necessário.

P: Onde altero meu aplicativo?

R: Provavelmente você está definindo o fator de trabalho construindo um BCryptPasswordEncoder assim:

new BCryptPasswordEncoder(31)

Pode aparecer em uma definição de bean assim:

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder(31);
}

Você pode procurar por essa string e atualizá-la. Observe que o fator de trabalho pode ser definido no seu aplicativo por uma propriedade externa, o que significa que você deve alterá-lo na sua configuração externa.

P: Acabei de atualizar o Spring Security e agora alguns ou todos os logins e registros de usuário estão travando. O que aconteceu?

R: A partir das versões 5.5.7+, 5.6.4+, 5.7.0+ do Spring Security, hashes de senha indicando um fator de trabalho de 31 — por exemplo, começando com '{bcrypt}$2a$31', '{bcrypt}$2b$31', '{bcrypt}$2y$31', '{bcrypt}$2$31', '$2a$31', '$2b$31', '$2y$31' ou '$2$31' — levarão de 2 a 3 dias para concluir cada cálculo de hash. Para aliviar isso, você precisará alterar o Spring Security para usar um número menor de rodadas. Em seguida, use esta ferramenta para atualizar os hashes de senha vulneráveis.

P: Concluí todas as três etapas recomendadas (alterar a configuração do BCryptPasswordEncoder, atualizar os hashes de senha e atualizar o Spring Security). Os hashes de senha modificados não estão sendo atualizados para o meu novo fator de trabalho configurado. O que devo fazer?

Certifique-se de que você tenha um bean do tipo UserDetailsPasswordService publicado. Esse bean é usado para atualizar senhas para um novo log de rodadas do BCrypt.

P: Por que o Spring Security não pode simplesmente atualizar as senhas vulneráveis no momento da atualização sem a necessidade desta ferramenta?

Primeiro, porque com o Spring Security mais recente, hashes de senha com fator de trabalho 31 são calculados corretamente e, portanto, levam de 2 a 3 dias para concluir cada um. É uma expectativa impraticável supor que esse seja um custo razoável para os aplicativos.

Segundo, o Spring Security só suporta o aumento do fator de trabalho (por exemplo, de 10 para 12), não a diminuição (por exemplo, de 31 para 10).