Quando desenvolvedores comparam MD5 vs SHA-256 vs bcrypt para armazenar senhas, o conselho usual é "MD5 está quebrado, use SHA-256". Esse conselho está errado e é o erro de segurança mais comum nessa área. MD5 está quebrado, sim. Mas o SHA-256 puro também é uma péssima escolha para senhas, por um motivo completamente diferente: é muito rápido. A resposta certa é um algoritmo deliberadamente lento, projetado para senhas, ou seja, bcrypt ou Argon2.
Este guia destaca a distinção que o resto da SERP ignora. Vamos abordar por que hashes rápidos perdem para GPUs, o que salting e fatores de trabalho realmente fazem e exatamente qual algoritmo usar em 2026. Você pode testar cada tipo de hash no navegador enquanto avançamos.
MD5 vs SHA-256 vs bcrypt de forma resumida#
O erro central é tratar todos os hashes como se fossem para a mesma função. Na verdade, são duas funções diferentes com requisitos opostos. A integridade de arquivos precisa de um hash rápido. O armazenamento de senhas precisa de um lento. Confundir esses papéis é o motivo pelo qual bancos de dados violados são quebrados em horas.
| Algoritmo | Tipo | Velocidade | Sal interno | Seguro para senhas? | Ideal para |
|---|---|---|---|---|---|
| MD5 | Hash rápido | Extremamente rápido | Não | Não (quebrado) | Nada relacionado à segurança |
| SHA-1 | Hash rápido | Muito rápido | Não | Não (quebrado) | Apenas compatibilidade legada |
| SHA-256 | Hash rápido | Muito rápido | Não | Não (muito rápido) | Checksums de arquivos, integridade, assinaturas |
| bcrypt | Hash lento (KDF) | Ajustável, lento | Sim | Sim | Armazenamento de senhas |
| Argon2id | Hash lento (KDF) | Ajustável, lento | Sim | Sim (melhor atual) | Armazenamento de senhas |
| PBKDF2 | Hash lento (KDF) | Ajustável, lento | Sim (você adiciona) | Sim (aceitável) | Ambientes com restrições FIPS |
Conclusão principal: SHA-256 é excelente para a função para a qual foi projetado (provar que um arquivo não foi alterado) e inseguro para uma função para a qual nunca foi projetado (resistir a hardware de quebra de senhas). "Hash seguro" não significa "seguro para senhas".
A palavra "seguro" causa a maior parte da confusão. SHA-256 é um membro da família SHA-2 e é criptograficamente seguro no sentido de que não é possível encontrar colisões ou revertê-lo matematicamente. Essa propriedade é o que a integridade de arquivos precisa. O armazenamento de senhas precisa de algo completamente diferente: resistência a força bruta em escala.
Por que o MD5 é Quebrado (e o SHA-1 Também)#
O MD5 falha em duas frentes. Primeiro, ele é quebrado por colisões: pesquisadores conseguem produzir deliberadamente duas entradas diferentes com o mesmo resumo MD5, o que destrói seu valor para assinaturas e certificados. O SHA-1 sofreu o mesmo problema com o trabalho prático de colisão publicado em 2017.
Segundo, e mais relevante para senhas, o MD5 é extremamente rápido. Uma GPU moderna pode calcular bilhões de hashes MD5 por segundo. Essa velocidade é uma vantagem para checksums, mas uma catástrofe para hashing de senhas.
Veja o que essa velocidade significa na prática. Se um site armazena senhas como MD5 puro e o banco de dados vaza, um invasor com uma única placa de vídeo comum pode testar um dicionário enorme de senhas comuns contra todas as contas quase instantaneamente. Adicione uma tabela arco-íris pré-computada (uma consulta gigante de hash para texto simples) e hashes MD5 sem sal de senhas comuns são revertidos em milissegundos.
- MD5: quebrado por colisões, muito rápido, sem sal. Nunca use para segurança.
- SHA-1: quebrado por colisões desde 2017, muito rápido. Depreciado em todos os lugares.
- A lição: "quebrado" aqui se refere parcialmente a colisões e parcialmente à velocidade bruta.
Você ainda pode usar MD5 ou SHA-256 com segurança para verificações de corrupção não adversariais (este arquivo foi baixado intacto?). Isso é integridade, não autenticidade, e não armazenamento de senhas. Para qualquer coisa que um invasor queira forjar ou quebrar, o MD5 está descartado.
A Armadilha do SHA-256: Seguro, mas Rápido Demais para Senhas#
Esta é a parte que a maioria das comparações erra. O SHA-256 não tem colisões quebradas. É um hash criptográfico genuinamente forte. Então por que é a ferramenta errada para senhas?
Porque é rápido de propósito. O SHA-256 foi projetado para que sistemas possam fazer hash de grandes quantidades de dados rapidamente para verificar integridade. Uma GPU de alto desempenho pode calcular na ordem de bilhões de hashes SHA-256 por segundo. Quando o algoritmo é rápido, a máquina de força bruta do invasor também é rápida.
Quebrar senhas é um jogo de adivinhação offline. Uma vez que o invasor tem seu banco de dados de hashes, nada limita a taxa de tentativas. Eles não estão fazendo login no seu site uma tentativa de cada vez. Eles estão executando seus hashes contra listas de palavras e regras de mutação em hardware dedicado. Quanto mais rápida sua função hash, mais tentativas por segundo eles conseguem, e mais barata fica cada senha quebrada.
Salgar ajuda, mas não resolve a velocidade#
Uma objeção comum é "basta salgar seu SHA-256". Um salt é um valor aleatório único armazenado junto com cada hash e misturado na entrada antes do hashing. Salgar é essencial e faz duas coisas reais:
- Derrota tabelas rainbow, pois uma tabela pré-computada é inútil contra salts aleatórios por usuário.
- Garante que dois usuários com a mesma senha obtenham hashes diferentes, então quebrar um não quebra o outro.
Mas salgar não faz nada quanto à velocidade. Um invasor ainda quebra cada hash SHA-256 salgado um de cada vez a bilhões de tentativas por segundo. O salt remove o atalho de pré-computação em massa; não torna a função subjacente lenta. É por isso que "SHA-256 salgado" é melhor que SHA-256 puro, mas ainda não é bom o suficiente para senhas.
O modelo mental: o salt protege contra pré-computação. Um algoritmo lento protege contra a taxa bruta de força bruta. Você precisa de ambos, e o SHA-256 só oferece um deles.
O que o bcrypt faz de diferente: lento de propósito#
O bcrypt foi projetado em 1999 especificamente para armazenamento de senhas, e sua ideia central é o oposto do MD5 e SHA-256: ele é deliberadamente e ajustavelmente lento. O bcrypt reúne três coisas que um hash de senha precisa.
- Um salt embutido. O bcrypt gera e armazena um salt por hash automaticamente, então você não pode esquecer de adicionar um.
- Um fator de trabalho (o "custo"). É um número que você define e que controla quantas iterações internas o bcrypt executa. Cada incremento de um aproximadamente dobra o tempo para calcular um hash.
- Um design adaptativo. Conforme o hardware fica mais rápido, você aumenta o fator de trabalho para manter o hashing lento, sem precisar mudar de algoritmo.
Uma string de hash bcrypt carrega seus próprios parâmetros. Um hash típico se parece com $2b$12$R9h/cIPz0gi..., onde $2b$ é a versão do bcrypt, 12 é o fator de trabalho (custo), e o restante é o salt e o digest combinados. Esse formato autodescritivo significa que a verificação precisa apenas do hash armazenado, não de uma coluna separada de salt.
O objetivo do fator de trabalho é tornar cada tentativa individual cara. Se um hash bcrypt leva um quarto de segundo para ser calculado, um invasor que poderia fazer bilhões de tentativas de SHA-256 por segundo agora fica reduzido a algumas tentativas de bcrypt por segundo por núcleo. A mesma lista de palavras que quebra SHA-256 em minutos pode levar anos contra um bcrypt bem configurado.
Escolhendo um fator de trabalho para bcrypt#
O fator de trabalho é um trade-off entre segurança e a latência de login do seu próprio servidor. Defina-o de modo que um único hash leve um tempo perceptível, mas tolerável, no seu hardware, normalmente ajustado para ficar na faixa de 0,1 a 0,5 segundos por hash.
- Um custo maior é mais seguro, mas retarda cada login e cada cadastro.
- Faça benchmark no seu hardware de produção real, não no seu laptop. Servidores mais rápidos podem suportar um custo maior.
- Reavalie anualmente. O hardware melhora, então um custo que era doloroso para invasores em 2020 é mais barato agora.
O bcrypt também tem uma peculiaridade que vale a pena conhecer: ele trunca a entrada em 72 bytes. Se você suportar frases-senha muito longas ou pré-hash de senhas (um padrão que algumas equipes usam), teste esse comportamento para não ignorar silenciosamente caracteres além do limite.
Onde o Argon2 se encaixa (e o PBKDF2)#
O bcrypt é excelente e ainda é uma escolha perfeitamente defensável em 2026. Mas a recomendação atual de guias de segurança como a folha de dicas de armazenamento de senhas da OWASP é o Argon2id, vencedor da Competição de Hashing de Senhas de 2015.
O Argon2id melhora o bcrypt por ser resistente a memória. O fator de trabalho do bcrypt custa tempo de CPU, mas usa pouca memória, o que permite que invasores coloquem muitos núcleos de cracking de bcrypt em hardware barato. O Argon2id permite ajustar três parâmetros: custo de tempo (iterações), custo de memória (quanta RAM cada hash precisa) e paralelismo. Forçar cada tentativa a consumir memória significativa reduz a vantagem de GPUs e ASICs que torna o cracking barato.
| Algoritmo | Resiste a cracking com GPU | Resistente a memória | Quando escolher |
|---|---|---|---|
| Argon2id | Forte | Sim | Novos sistemas; a recomendação padrão atual |
| bcrypt | Forte | Não | Maduro, testado em batalha; bom para sistemas existentes |
| scrypt | Forte | Sim | Alternativa válida resistente a memória se Argon2 não estiver disponível |
| PBKDF2 | Moderado | Não | Requisitos de conformidade FIPS-140; use contagens de iteração altas |
O PBKDF2 merece menção porque aparece em ambientes regulamentados. É mais antigo e não é resistente a memória, então resiste menos a GPUs que o bcrypt ou Argon2. Mas é aprovado pelo FIPS, o que importa para governo e alguns trabalhos corporativos. Se você precisar usar PBKDF2, aumente a contagem de iterações (centenas de milhares a milhões, ajustada ao seu orçamento de latência).
A versão resumida da árvore de decisão:
- Projeto novo sem restrições: use Argon2id.
- Sistema existente já usando bcrypt e funcionando: bcrypt está bom, mantenha-o, aumente o custo ao longo do tempo.
- Ambiente FIPS ou conformidade rigorosa: PBKDF2 com contagem de iterações muito alta.
- Nunca: MD5, SHA-1, SHA-256 puro, SHA-512 puro ou qualquer hash rápido sem sal.
Teste Cada Hash Você Mesmo#
Ler sobre hashes é uma coisa. Vê-los é outra, e faz a diferença de velocidade fazer sentido. Você pode gerar digests MD5, SHA-1, SHA-256 e SHA-512 da mesma entrada no navegador para ver como cada algoritmo transforma o texto.
Cole uma string de exemplo como correct horse battery staple no gerador de hash gratuito e veja-o produzir cada digest instantaneamente. Esse resultado instantâneo é exatamente o problema com hashes rápidos para senhas: se seu navegador calcula um digest SHA-256 sem atraso perceptível, imagine um farm de GPUs fazendo bilhões deles por segundo contra um banco de dados vazado.
Algumas coisas para testar enquanto experimenta:
- Faça o hash da mesma palavra duas vezes. Note que MD5 e SHA-256 produzem a mesma saída toda vez, por isso precisam de um salt externo e por que as rainbow tables funcionam contra eles.
- Altere um caractere. Todo o digest muda completamente (o efeito avalanche), o que é bom para verificações de integridade.
- Compare os comprimentos dos digests. SHA-256 é mais longo que MD5, mas o comprimento sozinho não o torna seguro para senhas. A velocidade é o verdadeiro problema.
Nota: uma ferramenta de hash rápido no lado do navegador é a maneira certa de aprender o que esses algoritmos produzem, mas não é onde você deve gerar hashes de senha em produção. bcrypt e Argon2 pertencem ao lado do servidor, na sua biblioteca de autenticação, nunca em JavaScript do cliente.
Enquanto pensa em segurança de credenciais, vale a pena verificar o quão resistentes são suas próprias senhas. Uma senha forte e um hash lento trabalham juntos: senhas fracas caem para qualquer hash, e um ótimo hash não pode salvar completamente uma senha que está em toda wordlist. Teste algumas no verificador de força de senha para ver como a previsibilidade e a entropia entram em jogo, e gere senhas genuinamente aleatórias com o gerador de senhas seguras para que a matemática de cracking esteja a seu favor.
Erros Comuns a Evitar#
A teoria é simples, mas os mesmos erros de implementação aparecem em violação após violação. Fique atento a estes.
- Usar SHA-256 porque é "mais seguro que MD5." É, sim, contra colisões. Ainda é rápido demais para senhas. Esta é a armadilha que este artigo inteiro existe para alertar.
- Criar seu próprio esquema como
sha256(sha256(senha) + salt). Empilhar hashes rápidos não cria um hash lento. Use um KDF de senha real. - Armazenar o salt incorretamente ou reutilizar um salt global. Os salts devem ser únicos e aleatórios por usuário. bcrypt e Argon2 lidam com isso para você, o que é mais um motivo para usá-los.
- Definir um fator de trabalho uma vez e nunca aumentá-lo. Um custo que prejudicava invasores anos atrás é barato agora. Reavalie-o.
- Fazer hash de senhas no JavaScript do lado do cliente. O hash deve ocorrer no servidor. Um hash do lado do cliente se torna apenas a nova senha que um invasor repete.
Se você também está lidando com tokens em vez de apenas senhas armazenadas, a mesma lógica "use a primitiva certa" se aplica a assinaturas e verificação. Nosso guia sobre decodificar vs verificar um JWT aborda um erro intimamente relacionado: confiar em um token que você apenas decodificou, mas nunca verificou criptograficamente.
O Veredito sobre MD5 vs SHA-256 vs bcrypt#
Para armazenamento de senhas, a classificação não é nem de perto equilibrada. O MD5 está quebrado e é rápido demais. O SHA-256 é criptograficamente forte, mas ainda é rápido demais, mesmo com sal, então ele perde para ataques de GPU por força bruta assim que seu banco de dados vazar. O bcrypt e o Argon2id são propositalmente lentos, aplicam sal automaticamente e permitem aumentar o custo conforme o hardware melhora, exatamente o que o armazenamento de senhas exige.
Portanto, quando alguém te perguntar sobre MD5 vs SHA-256 vs bcrypt para senhas, a resposta é bcrypt ou Argon2id, sempre. Reserve o SHA-256 para o que ele é realmente bom, como integridade de arquivos e checksums, e nunca deixe o rótulo de "hash seguro" te enganar a usar um algoritmo rápido onde um lento é necessário. Teste cada digest no gerador de hash gratuito para tornar a diferença de velocidade concreta, e mantenha os algoritmos lentos e específicos para senhas na sua camada de autenticação, onde eles pertencem.
Perguntas Frequentes#
O SHA-256 é seguro para senhas? Não, mesmo que o SHA-256 em si seja um hash criptográfico forte e não quebrado. O problema é a velocidade: o SHA-256 foi projetado para ser rápido, então um invasor com um banco de dados vazado pode fazer bilhões de tentativas por segundo em uma GPU. O uso de salt ajuda contra tabelas rainbow, mas não desacelera o algoritmo. Para senhas, use uma função deliberadamente lenta como bcrypt ou Argon2id.
Por que bcrypt é melhor que SHA-256 para senhas? O bcrypt é intencionalmente lento e ajustável, enquanto o SHA-256 é intencionalmente rápido. O bcrypt inclui um salt embutido e um fator de trabalho ajustável, então cada tentativa de adivinhar uma senha custa tempo e dinheiro reais para o invasor. Conforme o hardware melhora, você aumenta o fator de trabalho para manter o custo alto. O SHA-256 oferece tentativas baratas e de alto rendimento, que é o oposto do que o armazenamento de senhas precisa.
Devo usar bcrypt ou Argon2 em 2026? Ambos são sólidos. Argon2id é a recomendação atual porque é resistente a memória, o que reduz a vantagem de GPUs e ASICs que tornam a quebra barata. O bcrypt continua sendo uma escolha perfeitamente defensável e testada, especialmente se seu sistema já o utiliza. Para um projeto novo sem restrições de conformidade, opte por Argon2id; se você já usa bcrypt e ajusta o custo, não há motivo urgente para migrar.
Adicionar salt é suficiente para tornar o SHA-256 seguro para senhas? Não. O salt é necessário e você deve sempre usá-lo, mas ele resolve apenas um problema: impede o uso de tabelas rainbow pré-computadas e garante que senhas idênticas produzam hashes diferentes. O salt não faz nada quanto à velocidade do algoritmo, então um invasor ainda quebra cada hash SHA-256 com salt a bilhões de tentativas por segundo. Você precisa tanto de um salt único quanto de um algoritmo lento, que é exatamente o que bcrypt e Argon2 fornecem.
O MD5 é seguro para alguma coisa? Apenas para verificações de corrupção não relacionadas à segurança, como confirmar que um arquivo foi baixado sem erros. O MD5 tem colisões quebradas, então nunca deve ser usado para assinaturas digitais, certificados, senhas ou qualquer coisa que um invasor possa querer forjar ou quebrar. Mesmo para integridade de arquivos contra um adversário real, prefira SHA-256. Você pode ver como o MD5 se compara a outros resumos usando um gerador de hash gratuito.
O que é fator de trabalho no bcrypt? O fator de trabalho (também chamado de custo) é um número que controla quantas iterações internas o bcrypt realiza. Cada incremento de um dobra aproximadamente o tempo para calcular um único hash. Você o define para que um hash leve uma fração pequena, mas perceptível, de segundo em seu hardware de produção, o que mantém os logins rápidos para você enquanto torna a quebra em massa lenta para invasores. Aumente-o ao longo do tempo conforme o hardware fica mais rápido.
