MD5, SHA-256 ou bcrypt: qual hash usar e quando

O que é uma função hash

Uma função hash pega uma entrada de qualquer tamanho — uma palavra, um PDF de 4 GB, o conteúdo inteiro de um banco de dados — e devolve uma sequência de tamanho fixo, chamada de digest ou simplesmente "o hash". O SHA-256, por exemplo, sempre cospe 256 bits, ou seja, 64 caracteres hexadecimais, não importa se você alimentou a letra "a" ou a obra completa de Machado de Assis.

Três propriedades definem uma boa função hash criptográfica:

• Determinística: a mesma entrada gera sempre o mesmo digest.
• Efeito avalanche: mudar um único bit na entrada vira de cabeça para baixo praticamente todo o resultado.
• Resistente a colisão: deve ser inviável achar duas entradas diferentes com o mesmo hash.

O efeito avalanche fica óbvio com um exemplo. Veja o MD5 de duas senhas que diferem em um único dígito:

Mudou um caractere e o digest inteiro virou outro — não há nenhuma semelhança visível entre os dois. Você pode reproduzir isso agora mesmo no Hash MD5: digite as duas palavras e compare.

Hash não é criptografia (e por que isso importa)

Essa é a confusão mais comum, e ela leva a decisões de segurança erradas. Criptografia é uma operação de mão dupla: você embaralha os dados com uma chave e, com a mesma chave (ou a chave par), desembaralha tudo de volta. O objetivo é confidencialidade reversível.

Hash é de mão única. Não existe "des-hashear". O digest ba7816bf... não guarda a entrada original em lugar nenhum — ele a destrói por construção. Por isso ninguém deveria "criptografar senhas": senhas devem ser hasheadas, justamente porque você nunca precisa lê-las de volta. Para conferir o login, você hasheia o que o usuário digitou e compara com o digest guardado.

MD5 e SHA-1: por que estão aposentados para segurança

O MD5 foi criado por Ron Rivest em 1991 e produz 128 bits (32 caracteres hex). O SHA-1, de 1995, produz 160 bits (40 caracteres). Ambos foram pilares da internet por mais de uma década — e ambos estão quebrados para qualquer uso de segurança.

O problema é a resistência a colisão. Em 2004, pesquisadores demonstraram colisões de MD5 na prática; hoje você gera uma colisão de MD5 em segundos num notebook. O SHA-1 aguentou mais, até que em 2017 o ataque "SHAttered" (Google + CWI) produziu dois PDFs diferentes com exatamente o mesmo hash SHA-1. Em 2020 surgiu até a colisão de prefixo escolhido, mais perigosa, por cerca de 45 mil dólares de poder computacional.

Na prática, isso significa que um atacante pode forjar um arquivo malicioso com o mesmo digest de um arquivo legítimo. Por isso o MD5 e o SHA-1 saíram dos certificados TLS, das assinaturas digitais e dos sistemas de senha. O MD5 ainda tem usos não-criptográficos legítimos — como uma checagem rápida de corrupção acidental de arquivo, ou uma chave de cache — mas nunca onde um adversário pode trapacear.

SHA-256 e a família SHA-2: checksums e integridade

A família SHA-2, publicada pelo NIST em 2001, é o padrão atual para integridade. Os membros mais usados são o SHA-256 (256 bits / 64 hex) e o SHA-512 (512 bits / 128 hex). Não há nenhum ataque de colisão prático contra eles — é o que protege os certificados HTTPS que você usa todo dia e as transações do Bitcoin.

Compare os digests da string abc nos três algoritmos para sentir a diferença de tamanho:

O SHA-512 não é "mais seguro" no dia a dia — o SHA-256 já é robusto o suficiente — mas como ele opera em palavras de 64 bits, costuma ser até mais rápido em processadores modernos de 64 bits. Gere e compare os dois no Hash SHA-256 e no Hash SHA-512. Existe ainda o SHA-3 (Keccak), padronizado em 2015 com uma construção interna completamente diferente — ele serve como reserva caso algum dia o SHA-2 caia.

bcrypt, scrypt e Argon2: hashing de senhas

Aqui está a virada de chave: para senhas, você não quer SHA-256. Quer um algoritmo propositalmente lento. O bcrypt, criado em 1999 a partir da cifra Blowfish, foi desenhado exatamente para isso. Um hash bcrypt parece assim:

$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW

• $2b$ — identifica a versão do bcrypt.
• 12 — o fator de custo: significa 2¹² = 4096 iterações. Cada +1 dobra o trabalho.
• os 22 caracteres seguintes — o salt, gerado aleatoriamente e embutido no próprio hash.
• o resto — o digest da senha.

O scrypt (2009) e o Argon2 (vencedor da Password Hashing Competition em 2015) foram além: além de lentos, são memory-hard, ou seja, exigem bastante RAM. Isso atrapalha justamente os atacantes que usam GPUs e ASICs baratos para quebrar milhões de senhas em paralelo. Hoje a recomendação do OWASP é Argon2id; bcrypt segue sólido e onipresente. Você pode gerar e conferir um hash no Bcrypt — Gerador e Verificador.

Por que senhas precisam de hash lento e salt

Faça as contas. Uma GPU moderna calcula bilhões de SHA-256 por segundo. Se seu banco de senhas vazar com hashes SHA-256, um atacante testa todo um dicionário e bilhões de combinações em horas. Com bcrypt no custo 12, a mesma GPU faz talvez alguns milhares de tentativas por segundo — a diferença entre quebrar a senha numa tarde e levar séculos.

O salt resolve outro problema. Sem salt, duas pessoas com a senha "123456" teriam o mesmo digest, e o atacante usaria uma rainbow table (tabela pré-calculada) para reverter milhões de hashes de uma vez. Com um salt aleatório por usuário, cada hash é único e as tabelas pré-calculadas viram inúteis. Muitos times ainda adicionam um pepper — um segredo guardado fora do banco — como camada extra.

Verificando a integridade de um arquivo na prática

Quando você baixa uma imagem ISO do Linux ou um instalador, o site geralmente publica o SHA-256 esperado ao lado do link. O fluxo é simples:

1. Baixe o arquivo.
2. Calcule o SHA-256 dele localmente.
3. Compare, caractere por caractere, com o valor publicado.

Se bater, o arquivo chegou íntegro; se diferir em um só dígito, ele foi corrompido no caminho ou adulterado. O Hash de Arquivo (Checksum) faz esse cálculo direto no navegador, sem enviar nada para um servidor. Vale lembrar: o checksum só é confiável se a página que o publica também for — um atacante que controle o site pode trocar o arquivo e o hash.

A mesma ideia protege o que seu site carrega de CDNs externas. O atributo integrity de uma tag <script> guarda um hash (SHA-384, por exemplo) do arquivo esperado; o navegador recalcula e recusa carregar se não bater. É o chamado Subresource Integrity, e você gera esse valor no Gerador de SRI Hash.

Perguntas frequentes

Posso usar SHA-256 para guardar senhas?

Tecnicamente funciona, mas é uma má ideia. SHA-256 é rápido demais — exatamente o que o atacante quer. Use bcrypt, scrypt ou Argon2id, que são lentos e salgados por padrão. SHA-256 fica para integridade e checksums, não para senhas.

É possível "descriptografar" um hash MD5?

Não, porque hash não é criptografia e não há chave para reverter. O que existe são bancos de dados de hashes já calculados para senhas comuns. Se a sua senha for fraca, ela pode estar nessas tabelas; uma senha longa e única, com salt, não está.

MD5 é totalmente inútil hoje?

Para segurança, sim. Para detectar corrupção acidental de um arquivo ou servir como chave de cache, ainda é rápido e suficiente — desde que nenhum adversário tenha interesse em forjar uma colisão.

Por que dois hashes diferentes do mesmo arquivo?

Quase sempre é diferença de algoritmo (MD5 vs SHA-256) ou de codificação do texto (uma quebra de linha extra, espaços, UTF-8 vs Latin-1). Calcule o hash do arquivo binário, não de uma versão re-salva pelo editor, e use exatamente o mesmo algoritmo dos dois lados.

O que é o fator de custo do bcrypt?

É um número que define quantas iterações o algoritmo faz: custo 12 equivale a 2¹² = 4096 rodadas. Subir o custo deixa o hash mais lento de calcular — bom contra atacantes, mas você deve ajustá-lo para não pesar demais no seu servidor a cada login (algo na faixa de 200 a 300 ms costuma ser um bom equilíbrio).