Glossário
O que é hashing de senha? Armazenar senhas com segurança usando uma transformação irreversível
O hashing de senha armazena senhas com uma transformação de mão única e irreversível. A diferença para a criptografia, por que MD5/SHA-256 puro é inseguro e a resposta certa: um sal por usuário mais um hash lento (bcrypt/Argon2/scrypt).
"Nunca armazene uma senha como está no banco de dados" — então como você a armazena? A resposta é hashing. Veja como funciona e os pontos-chave para fazê-lo com segurança (sem passos de ataque).
Hashing ≠ criptografia
Esses dois são confundidos, mas os objetivos são opostos. A criptografia é "reversível com uma chave, para você poder lê-la de volta depois". O hashing é "de mão única — você não consegue revertê-lo". Uma senha é uma informação que nem mesmo o operador deveria precisar ler de volta, então um hash deliberadamente irreversível é o encaixe certo.
Criptografia (reversível)
texto puro ⇄ texto cifrado. a chave reverte. para dados que você lê de volta
Hashing (mão única)
senha → hash. não pode ser revertido. para armazenar senhas
No login, você verifica "aplicar o hash na senha digitada do mesmo jeito e ver se bate com o hash armazenado." Você nunca precisa recuperar a original.
Por que "MD5/SHA-256 puro" não basta
MD5 e SHA-256 são hashes rápidos. Isso é uma propriedade útil em outros contextos, mas uma fraqueza para o armazenamento de senhas: um invasor consegue computar um número enorme de tentativas por segundo contra um hash vazado.
- Rainbow tables: uma tabela pré-computada gigante de "senha comum → seu hash". Com um hash puro, uma correspondência é encontrada só consultando-a.
- Força bruta: quanto mais rápido o hash, mais tentativas por unidade de tempo — ou seja, mais fácil de quebrar.
As duas correções
Adicione um sal (um valor diferente por usuário)
Antes do hashing, misture um valor aleatório que difere por usuário (um sal). Agora a mesma senha é armazenada de forma diferente para cada um, o que derrota as rainbow tables e impede que uma única execução de quebra cubra senhas reutilizadas em várias contas.
Use um hash deliberadamente lento e feito para isso
bcrypt / Argon2 / scrypt permitem tornar o cálculo intencionalmente caro (um parâmetro de custo). Uma lentidão que ninguém percebe em um login legítimo derruba a força bruta do invasor a uma taxa impraticável. O sal também já está embutido neles.
A visão deste site: não construa você mesmo
"Com certeza MD5 mais um sal já basta?" — essa é a armadilha clássica. O armazenamento seguro de senhas também depende de gerar e armazenar o sal, ajustar o custo e lidar com diferenças de tempo. Em vez de montar isso você mesmo, apoie-se na função oficial de senha da sua linguagem/framework (a maioria usa bcrypt/Argon2 por baixo). Para novos sistemas, faça do Argon2id sua primeira escolha.
Leia a seguir
- Glossário: o que é um sal (o "tempero" por usuário que derrota ataques de reuso)
- Aprenda: como armazenar senhas com segurança (hashing + sal na prática)
- Fundamentos: armazenando senhas do jeito certo (chega de texto puro) / escolhendo um gerenciador de senhas
FAQ
QComo o hashing difere da criptografia?
A criptografia é reversível: com a chave você descriptografa os dados de volta, que é o que se quer para dados que você vai ler novamente. O hashing é de mão única — você não consegue revertê-lo. Uma senha não precisa, de fato, ser lida de volta, nem mesmo por você, então um hash deliberadamente irreversível serve. Mesmo que o banco de dados seja roubado, você não consegue extrair as senhas originais direto dos hashes.
QHashing com MD5 ou SHA-256 é seguro o bastante?
Não, não por si só. MD5/SHA-256 são hashes 'rápidos', então um invasor consegue testar um número enorme de tentativas por segundo, e senhas comuns caem diante de força bruta ou rainbow tables (tabelas de consulta pré-computadas). Para deixá-lo seguro, adicione um 'sal' por usuário e use um hash deliberadamente lento e feito para isso (bcrypt, Argon2 ou scrypt).
QQual eu devo realmente usar?
Para novos sistemas, Argon2 (especialmente Argon2id) é a primeira escolha, com bcrypt ou scrypt como alternativas sólidas. Todos eles já trazem o sal e um fator de custo ajustável no design. Em vez de montar MD5+sal você mesmo, use essas implementações padrão (as funções oficiais da sua linguagem/framework) — é mais seguro e confiável.