SHAttered expõe o custo de manter criptografia legada

Pesquisadores do Google e do CWI Amsterdam anunciaram o SHAttered, a primeira colisão pública prática para SHA-1. Eles produziram dois arquivos PDF diferentes com o mesmo hash SHA-1.¹ O resultado não aparece do nada: a comunidade de segurança já alerta há anos que SHA-1 está no fim da vida útil. A diferença é que o risco deixa de ser argumento acadêmico e vira demonstração concreta.

Hash criptográfico é usado para garantir integridade, identificar conteúdo, assinar artefatos, comparar arquivos e sustentar cadeias de confiança. Quando duas entradas distintas podem gerar o mesmo resumo de forma viável, sistemas que dependem do algoritmo passam a aceitar ambiguidade onde deveriam exigir prova. O próprio material do projeto destaca esse ponto ao demonstrar dois PDFs diferentes com a mesma impressão SHA-1.²

O problema não era só o SHA-1

O caso SHAttered expõe um padrão recorrente em empresas de TI: componentes antigos permanecem em produção muito depois de perderem margem de segurança. SHA-1 já vem sendo removido de certificados TLS e de navegadores, mas ainda aparece em repositórios, integrações internas, arquivos assinados, appliances, bibliotecas antigas e protocolos que ninguém quer mexer porque "sempre funcionaram".

Esse tipo de dependência é perigoso porque raramente aparece como item isolado no backlog. Ele está embutido em pipelines de build, rotinas de assinatura, contratos com fornecedores, bases de dados históricas e sistemas de auditoria. A migração exige inventário, testes e compatibilidade. Por isso, quando a prova pública chega, a empresa descobre que não sabe onde usa o algoritmo.

O recado é claro: SHA-1 não deve mais ser usado para segurança prática. Mesmo quando uma colisão específica não permite quebrar automaticamente todo sistema, ela reduz a confiança em assinaturas, identificadores e verificações que dependem da resistência a colisões.

Migração criptográfica precisa de engenharia

Trocar um algoritmo em produção não é apenas alterar uma constante de configuração. Uma migração responsável começa por mapear usos: certificados, assinaturas de documentos, checksums, autenticação, armazenamento de senhas, integridade de backups, APIs de terceiros e formatos de arquivo.

Depois vem a escolha do substituto adequado. Para hashes de integridade e assinatura, famílias como SHA-256 e SHA-3 entram no debate. Para senhas, o assunto é outro: algoritmos de hash rápido não bastam; entram funções próprias para derivação e armazenamento, como bcrypt, scrypt, Argon2 ou PBKDF2, conforme contexto e suporte.

Também é importante planejar coexistência. Sistemas com dados históricos podem precisar aceitar verificações antigas por um período, mas emitir novos artefatos apenas com algoritmos modernos. Logs devem indicar quando uma validação antiga ocorreu. Métricas ajudam a saber quando o uso antigo finalmente desapareceu.

O risco corporativo é a falsa estabilidade

O SHAttered não deve ser lido como curiosidade criptográfica. No ambiente corporativo, ele sinaliza que segurança tem prazo de validade. Um algoritmo aceitável em uma década pode se tornar frágil na seguinte por avanço computacional, pesquisa acadêmica, redução de custo de hardware ou mudança no modelo de ataque.

O erro de governança é esperar o colapso público para agir. Migração criptográfica precisa entrar em gestão de ciclo de vida: dependências monitoradas, políticas de algoritmo mínimo, revisão periódica de certificados, atualização de bibliotecas e critérios claros para rejeitar integrações inseguras.

O SHA-1 agora está "quebrado" aos olhos do público técnico. Mas a lição mais importante é sobre inventário. Empresas que não sabem onde usam criptografia também não sabem quanto tempo levarão para trocar quando a próxima peça antiga deixar de ser defensável.