Como o 'Fortalecimento da Criptografia' Quebrou a Autenticação: FreshRSS e o Limite de 72 Bytes do bcrypt

A CVE-2025-68402 não é um erro de implementação aleatória, é um caso clássico de 'fortalecimento criptográfico' mal aplicado. Trocar SHA-1 por SHA-256 no nonce parecia uma melhoria óbvia, mas ignorou uma regra fundamental do bcrypt: ele lê apenas os primeiros 72 bytes da entrada e descarta o restante sem aviso. Como o nonce passou de 40 para 64 caracteres hexadecimais (128 bytes em UTF-8), a concatenação $nonce . $hash deixou apenas 8 bytes disponíveis para o hash real da senha, o suficiente para o prefixo $2y$10$ e um pedaço do salt, mas zero bytes para os dados que dependem da senha. Resultado: password_verify() validava qualquer senha digitada.

O erro se repete em outros projetos: a Okta sofreu com CVE-2025-61884 por concatenar identificadores longos antes do hash, e o Spring Security teve CVE-2025-22228 por não tratar senhas acima de 72 caracteres como inválidas antes de chamar matches(). A lição não é trocar algoritmos, mas entender como eles lidam com entradas compostas, e testar o comportamento sob limite, não só sob condição ideal.

Empresas que usam FreshRSS em ambientes corporativos ou governamentais para agregação de feeds de segurança, inteligência de ameaças ou monitoramento regulatório poderiam ter exposto credenciais de acesso a sistemas internos, mesmo sem ter implantado a branch edge, pois alguns administradores testam versões de desenvolvimento em ambientes paralelos. Mais grave: essa falha mostra como decisões técnicas bem-intencionadas (como migrar para SHA-256) viram vetores de ataque quando feitas sem revisão de impacto em camadas inferiores, como funções de verificação de senha. Não é sobre 'criptografia forte', mas sobre composição segura de primitivas.