Por Que Você Não Deve Guardar Senha com SHA-256 (nem com MD5)

Existe um erro de segurança que aparece em praticamente todo sistema feito às pressas, e ele tem aparência de acerto. O desenvolvedor sabe que não se guarda senha em texto puro. Então aplica um SHA-256 antes de salvar no banco, marca a tarefa como resolvida e segue em frente.

O problema é que o SHA-256 foi projetado para ser rápido — e velocidade é precisamente o que o atacante precisa.

O ataque começa depois do vazamento

Para entender por que velocidade é o problema, é preciso olhar o cenário em que o hash de senha importa: o banco de dados já vazou. O atacante está com a tabela de usuários na mão, com todos os resumos. A pergunta que resta é quanto tempo ele leva para transformar aqueles resumos em senhas.

E aí a conta é simples. Uma placa de vídeo comum calcula bilhões de SHA-256 por segundo. Uma máquina com algumas delas testa todas as senhas de oito caracteres de um alfabeto comum em questão de horas. Não é preciso quebrar o algoritmo: basta gerar candidatos e comparar.

Com listas de senhas já vazadas — e existem bilhões de senhas reais em circulação — a maioria das contas cai em minutos, porque a maioria das pessoas não inventa senha aleatória.

O SHA-256 fez exatamente o que prometia. O erro foi usá-lo para uma tarefa em que rapidez é defeito.

A tabela pronta, e o que a neutraliza

Antes de falar do algoritmo certo, vale entender o segundo problema. Se o hash é sempre o mesmo para a mesma senha, dá para calcular uma vez e reaproveitar para sempre — e é isso que são as rainbow tables: tabelas gigantes de senhas comuns com os resumos correspondentes, prontas para consulta. O atacante nem precisa calcular nada; ele procura.

Pior: se dois usuários do seu sistema têm a mesma senha, os dois resumos são idênticos no banco. Qualquer pessoa que olhe a tabela percebe isso, e uma senha descoberta abre as duas contas.

A solução é o salt: um valor aleatório, diferente para cada usuário, misturado à senha antes do hash. Com salt, a mesma senha gera resumos diferentes para cada pessoa, e nenhuma tabela pré-calculada serve — o atacante teria que montar uma tabela nova para cada usuário.

O salt não é secreto. Ele fica guardado ao lado do hash, no mesmo banco, e isso é esperado. O trabalho dele não é esconder nada: é tornar o pré-cálculo inútil.

O que "hash lento" quer dizer

A resposta para o problema da velocidade é usar uma função projetada para ser deliberadamente cara. Elas são chamadas de funções de derivação de chave, e a lentidão é um parâmetro que você escolhe.

A lógica é assimétrica e é o ponto central de tudo:

• Para o seu servidor, cada verificação custa uns 100 milissegundos. Uma pessoa faz login e nem percebe.
• Para o atacante, cada tentativa custa os mesmos 100 milissegundos. E ele precisa de bilhões.

O mesmo custo que é irrelevante uma vez por login torna o ataque inviável quando multiplicado por bilhões de tentativas. É só isso — mas é tudo.

As funções modernas vão além do tempo e também exigem memória. Isso é importante porque uma placa de vídeo tem milhares de núcleos, mas memória limitada: um algoritmo que precisa de dezenas de megabytes por tentativa reduz drasticamente quantas tentativas cabem em paralelo, e derruba justamente a vantagem do hardware especializado.

A recomendação atual

O OWASP mantém uma orientação sobre armazenamento de senha, e ela é direta ao dizer que algoritmos rápidos como o SHA-256 não servem para essa finalidade. A ordem de preferência é:

Repare que o SHA-256 aparece na última linha — mas dentro do PBKDF2, repetido 600 mil vezes. É essa repetição que transforma uma função rápida em algo caro. Usado sozinho, uma vez, ele não oferece proteção alguma nesse cenário.

Uma observação prática sobre o bcrypt: ele ignora tudo além dos 72 primeiros bytes da entrada. Com uma frase-senha longa, ou com uma senha que já passou por um hash antes, isso pode truncar silenciosamente o que importa.

O que fazer no seu sistema

Se você está começando: use a biblioteca padrão da sua linguagem ou do seu framework. Praticamente todos já têm Argon2id ou bcrypt pronto, com salt gerado automaticamente e guardado junto do hash, no formato certo. Você não precisa escrever nada disso — e não deveria.

Se você tem SHA-256 em produção: a migração é mais simples do que parece, porque não é preciso conhecer as senhas. No próximo login bem-sucedido de cada pessoa, você tem a senha em texto por um instante: recalcule com o algoritmo novo e substitua o registro. Quem não voltar em alguns meses passa por uma redefinição forçada. É um caminho gradual e sem interrupção.

Em qualquer caso: não invente esquema próprio. "SHA-256 aplicado dez mil vezes com sal e pimenta" soa razoável e não é: o número de iterações que alguém escolhe no olho costuma ser baixo demais, e construções caseiras têm um histórico ruim de introduzir fraquezas que ninguém percebe até vazarem.

Onde o hash rápido continua sendo o certo

Nada disso desqualifica o SHA-256. Ele é excelente no que foi feito para fazer: verificar integridade de arquivo, identificar conteúdo, comparar dois valores sem transmiti-los, assinar digitalmente. Nessas tarefas, a velocidade é uma virtude — e é por isso que ele está em toda parte.

O que não dá é usar a mesma ferramenta nos dois casos. Guardar senha é um problema adversarial em que o defensor calcula uma vez e o atacante calcula bilhões; qualquer coisa que barateie o cálculo ajuda o lado errado.

Se você quer ver o SHA-256 funcionando, o gerador de hash calcula os quatro algoritmos da família SHA direto no navegador. E, se o assunto é a sua própria senha, o gerador de senhas monta senhas e frases secretas com entropia real — o que, do lado de quem usa o sistema, é a única defesa que independe de o outro lado ter feito a coisa certa.