MD5, SHA-1 e SHA-256: como escolher um hash
Um hash resume um ficheiro ou mensagem numa cadeia curta, mas essa palavra não resolve sozinha uma questão de segurança. MD5, SHA-1 e SHA-256 têm histórias e propriedades diferentes. Uma correspondência pode detetar uma alteração numa transferência quando o valor esperado vem de um editor fiável. Não prova por si quem publicou o ficheiro, não protege uma base de dados de palavras-passe e não torna autêntica uma transferência sem assinatura. Antes de escolher um algoritmo, é preciso separar esses trabalhos.
O problema
Uma função de hash criptográfica recebe bytes de qualquer tamanho e devolve um resumo de tamanho fixo. É determinística: os mesmos bytes geram o mesmo resultado. Foi também concebida para que alterar bytes mude o resultado de uma forma difícil de prever. Por isso é útil para verificar integridade, identificar artefactos de compilação e construir assinaturas. Isso não significa que todos os algoritmos resistam da mesma forma a um adversário deliberado.
MD5 produz 128 bits e SHA-1 produz 160. RFC 6151 e RFC 6194 documentam ataques de colisão e desaconselham ambos quando a resistência a colisões é importante. Uma colisão significa conseguir construir duas entradas diferentes com o mesmo hash. SHA-256 pertence à família SHA-2, definida no FIPS 180-4, e é a escolha habitual entre estes três para uma nova verificação geral de integridade. Não é, por isso, autenticação de origem nem armazenamento seguro de palavras-passe.
A primeira pergunta não é qual texto hexadecimal parece mais forte, mas que decisão irá suportar. Detetar corrupção acidental, guardar um verificador de palavra-passe, provar que um editor aprovou uma versão e assinar um registo são problemas diferentes. Cada um atravessa uma fronteira de confiança própria e costuma precisar de uma construção diferente em redor de um hash.
Exemplo prático
Imagine que um projeto publica `tool-4.2.zip` e o respetivo SHA-256 na página HTTPS oficial da versão. Depois de transferir o ficheiro, calcule SHA-256 sobre os bytes recebidos e compare todos os caracteres com o valor daquela página fiável. Se forem diferentes, pare: o ficheiro pode estar incompleto, alterado ou ser outra versão. Se coincidirem, os bytes locais coincidem com os bytes representados pela referência publicada.
Essa conclusão tem uma condição decisiva. Se alguém conseguir substituir tanto o ZIP como o checksum da página, continuará a existir uma correspondência. A comparação não prova a identidade do editor; prova igualdade com a referência obtida. Um checksum copiado de um espelho desconhecido, de uma mensagem sem assinatura ou de um resultado de pesquisa não tem autoridade independente. Obtenha metadados por um canal controlado pelo editor e confirme a identidade separadamente.
As palavras-passe mostram o contraste. Um serviço não deve guardar um MD5, SHA-1 ou SHA-256 direto da palavra-passe como desenho da sua base de dados. Hashes gerais rápidos permitem testar muitas palavras candidatas depois de uma fuga. O armazenamento precisa de um esquema próprio, com sal e custo adaptativo de computação ou memória, escolhido e configurado pelo serviço. Comparar uma transferência não é guardar palavras-passe.
Procedimento
Para verificar uma transferência, identifique antes o nome exato, a versão e o editor. Transfira a partir da localização oficial da versão quando possível. Obtenha o checksum noutra localização fiável ou num manifesto assinado, se o editor o disponibilizar. Mantenha juntos o nome do ficheiro e o hash para não comparar por engano o ZIP 4.2 com o checksum de 4.1.
Calcule SHA-256 sobre o ficheiro original transferido, não sobre uma pasta extraída nem sobre um documento que outra aplicação abriu e guardou novamente. Copie o resumo hexadecimal completo. A comparação deve rejeitar uma diferença; não deve cortar, normalizar ou modificar bytes em silêncio. Se não coincidir, elimine ou coloque em quarentena a transferência e obtenha-a de novo. Não altere o valor esperado apenas para obter uma indicação positiva.
Quando for necessária evidência mais forte da origem, siga as instruções de verificação de assinatura do editor. Uma assinatura digital liga dados de versão a uma chave privada; é validada com a chave pública associada e com uma decisão de confiança sobre essa chave. Confirme a impressão digital da chave ou certificado por um canal fiável, valide a assinatura sobre os metadados corretos e reveja revogações ou alterações de chave. Uma assinatura também depende de uma distribuição e política de chaves adequadas.
Explicação técnica
Resistência a colisões pergunta se um atacante consegue encontrar duas entradas diferentes com o mesmo hash. Resistência a pré-imagem pergunta se, dado um hash, consegue encontrar uma entrada que o produza. Resistência a segunda pré-imagem pergunta se, dada uma entrada, encontra outra diferente com o mesmo resultado. São propriedades relacionadas, mas não substituíveis. Um protocolo deve declarar qual precisa, em vez de usar o tamanho do resumo como uma pontuação universal.
As colisões práticas conhecidas tornam MD5 e SHA-1 impróprios para novos usos sensíveis a colisões, como certificados, artefactos assinados e fluxos documentais. Um sistema legado pode ainda apresentá-los por compatibilidade ou como identificadores sem objetivo de segurança; a presença não é recomendação. Para uma convenção nova de integridade de ficheiros, SHA-256 é preferível, embora um protocolo específico possa exigir outro algoritmo ou formato normalizado.
Um hash não contém data, nome de editor nem promessa de que seja seguro executar um ficheiro. Software malicioso pode ter um SHA-256 perfeitamente válido se o atacante forneceu também a referência. Do mesmo modo, uma assinatura válida diz que uma chave concreta assinou dados; não substitui confirmar que a chave pertence ao editor esperado nem avaliar se o software é adequado ao ambiente.
Erros frequentes
Um erro comum é considerar MD5 ou SHA-1 aceitáveis porque uma ferramenta ainda os apresenta. A disponibilidade mantém interoperabilidade, não adequação de segurança. Outro erro é usar SHA-256 diretamente para palavras-passe por ser mais recente que MD5. A velocidade que facilita resumir um ficheiro grande também facilita adivinhar palavras-passe offline. Esquemas de palavras-passe adicionam sal e custo deliberado, configurado conforme o modelo de ameaça e o hardware.
Também falha comparar apenas um prefixo, aceitar mudanças de maiúsculas ou espaços sem entender o formato, ou calcular o hash de uma representação textual em vez do ficheiro binário. Estes erros criam correspondências enganadoras ou escondem diferenças. Use o formato documentado pelo editor, mantenha o valor completo e repita o cálculo depois de voltar a transferir.
Não publique um checksum junto de uma transferência chamando-lhe assinatura. Só é útil contra corrupção acidental se a referência já for fiável. Se a origem importa, publique assinaturas verificáveis, instruções claras de distribuição de chaves e passos da versão. Não importe uma chave a partir de comentários, pedidos ou mensagens coladas sem uma verificação independente.
Considerações
Aplicar hash pode revelar informação sobre entradas de baixa entropia. Se um valor vem de um conjunto pequeno e previsível, outra pessoa pode calcular candidatos e comparar resultados. Não trate um hash como anonimização de nomes, endereços de correio, identificadores curtos ou palavras-passe. Sais, controlos de acesso e minimização de dados são controlos diferentes para riscos diferentes.
As verificações de integridade exigem também disciplina operacional. Na automatização de versões, registe algoritmo, hash completo, artefacto, versão, URL de origem e data. Gere o checksum a partir da saída reprodutível da compilação quando for viável e proteja o canal de publicação. Num exercício, teste um artefacto modificado de propósito para confirmar que a diferença interrompe o fluxo. Estas práticas reduzem erros acidentais sem afirmar que um hash isolado autentica software.
Ao usar um gerador local de hashes, trate apenas material que tem direito de processar. Para ficheiros sensíveis, prefira um comando local verificado do sistema operativo ou o processo interno aprovado. Uma ferramenta no navegador pode demonstrar um cálculo, mas não atesta a proveniência da entrada, a fiabilidade da referência copiada nem a política de segurança do destinatário.
Limitações
Este guia é uma comparação conceptual. Não substitui o procedimento de verificação de um fornecedor, uma revisão criptográfica ou resposta a incidentes. Não certifica uma versão, chave, sítio, gestor de palavras-passe ou implementação de hash. As normas e os ataques evoluem; em sistemas de grande impacto, consulte a orientação atual do editor e os requisitos do protocolo aplicável.
Também não fornece uma chave privada, uma palavra-passe utilizável ou instruções para contornar verificações. Se surgir uma diferença de checksum em software necessário para trabalhar, preserve a evidência exigida pela sua organização, contacte o editor oficial e use uma fonte conhecida como boa. Não distribua o artefacto suspeito apenas para que outras pessoas o comparem.
Lista de verificação
Escolha SHA-256, e não MD5 ou SHA-1, para um checksum geral novo. Compare o resumo completo dos bytes exatos com uma referência obtida por um canal fiável do editor. Uma correspondência significa igualdade com essa referência, não prova de identidade. Use assinaturas e chaves verificadas quando a origem importar. Para palavras-passe, use um esquema adaptativo com sal, nunca MD5, SHA-1 ou SHA-256 isolados. Guarde algoritmo, artefacto, versão, origem e resultado juntos e pare perante qualquer diferença.