"Sal" surge no momento em que você fala sobre hashing de senha. Adicionar um valor aleatório antes do hash muda drasticamente o cenário de segurança. Veja como funciona e os pontos-chave (sem passos de ataque).
Por que um sal deixa as senhas mais seguras
Sem um sal, usuários com a mesma senha obtêm o mesmo hash armazenado. Isso dá ao invasor duas opções: procurar a senha direto em uma tabela pré-computada (uma rainbow table) e reaproveitar o resultado da quebra de uma conta para todos com a mesma senha.
Adicione um sal e a mesma "password123" é armazenada como algo completamente diferente para cada usuário.
Pelo mesmo motivo, um sal precisa ser gerado de novo para cada usuário (idealmente para cada senha). Se todos compartilham um único sal, usuários com a mesma senha voltam a ter valores armazenados iguais, e a maior parte do benefício se perde. Use um gerador de números aleatórios criptográfico, difícil de prever, e armazene o sal junto com o hash (ele não precisa ser secreto).
Um sal só protege contra tabelas pré-computadas e a quebra em massa de senhas reutilizadas. Desacelerar um ataque de força bruta contra uma única senha não é o trabalho dele; isso fica a cargo de um hash deliberadamente lento, como bcrypt/Argon2. Eles cobrem ameaças diferentes, então use sempre os dois.
Tamanho do sal e como gerá-lo
Dois documentos definem a base:
- NIST SP 800-63B-4 (a diretriz de autenticação dos EUA): o sal precisa ter pelo menos 32 bits e ser escolhido de modo que os sais armazenados raramente coincidam. Tanto o sal quanto o hash são armazenados para cada senha
- RFC 9106 (a especificação do Argon2): 16 bytes (128 bits) são recomendados para hashing de senhas, podendo cair para 64 bits onde o espaço é limitado
Três regras para gerá-lo:
- Use um gerador de números aleatórios criptográfico. Use a função aleatória segura da sua linguagem, não funções previsíveis como
Math.random()ou omt_rand()do PHP - Não use valores adivinháveis: nome de usuário, endereço de e-mail, ID do usuário ou horário de cadastro não substituem um sal
- Gere um novo sal quando a senha mudar. Manter o antigo deixa um vínculo entre o hash antigo e o novo
Na prática, as implementações padrão de bcrypt, Argon2 e scrypt atendem a tudo isso automaticamente. Se você está escrevendo código que cria sais por conta própria, trate isso como um sinal para revisá-lo.
Sal vs pimenta vs alongamento de chave
O armazenamento de senhas envolve três medidas de nomes parecidos. Elas defendem contra coisas diferentes, então nenhuma substitui a outra.
| Sal | Pimenta (pepper) | Alongamento de chave (hash lento) | |
|---|---|---|---|
| O que é | Um valor aleatório por usuário | Um valor secreto compartilhado por todos os usuários | Tornar o cálculo do hash deliberadamente caro |
| É secreto? | Não (armazenado com o hash) | Sim (mantido fora do banco de dados) | As configurações não precisam ser secretas |
| Defende contra | Tabelas pré-computadas, quebra em massa de senhas idênticas | Quebra quando só o banco de dados vaza | Força bruta contra cada hash |
| Implementação | Adicionado automaticamente por bcrypt/Argon2 | Adicionada por você, se necessário | Custo do bcrypt, memória e iterações do Argon2 |
O NIST SP 800-63B-4 recomenda que uma "chave secreta conhecida só pelo verificador" (o que normalmente se chama de pimenta) seja armazenada separadamente dos hashes de senha, de preferência dentro de hardware dedicado, como um HSM.
Caso real: armazenamento sem sal no LinkedIn (2012)
Em junho de 2012, foi noticiado que cerca de 6,5 milhões de hashes de senha supostamente de usuários do LinkedIn haviam sido publicados na internet. O LinkedIn confirmou que parte deles correspondia a contas do LinkedIn e desativou as senhas dos membros afetados.
Em seu blog oficial, a empresa disse que vinha migrando de um sistema que só fazia o hash das senhas para outro que fazia o hash e adicionava sal. Na época, especialistas citados pela imprensa criticaram a empresa por proteger as senhas apenas com hash SHA-1.
Duas lições:
- Hashes sem sal permitem recuperar senhas comuns em massa a partir de tabelas pré-computadas
- Mesmo no meio de uma migração, se continuam existindo hashes no formato antigo, o impacto de um vazamento é decidido por esse formato antigo
Como verificar no seu próprio ambiente
Observe o formato das strings armazenadas
Em um banco de dados de desenvolvimento que você controla, olhe alguns valores de senha. No bcrypt, os 22 caracteres depois de $2b$12$ são o sal. No Argon2, $argon2id$v=19$m=…,t=…,p=…$ é seguido pelo sal e pelo hash separados por $. Se o valor não tem nenhum desses formatos e não há uma coluna separada para o sal, as senhas podem estar armazenadas sem sal.
Crie duas contas de teste com a mesma senha
Em um ambiente de desenvolvimento, cadastre duas contas de teste com a mesma senha e compare os valores armazenados. Se forem iguais, o sal não está funcionando. Confirme também que a parte do sal muda quando a senha é trocada.
Procure código que monta sais à mão
Procure no código a palavra salt e lugares que combinam funções aleatórias ou de hash à mão. Se encontrar uma função aleatória previsível, um nome de usuário ou ID reaproveitado, ou uma string fixa, substitua por uma função de senha padrão da sua linguagem ou framework.
Use o guia prático para a migração
Como migrar de um armazenamento sem sal (por exemplo, refazendo o hash no login) e as configurações recomendadas para cada algoritmo estão em como armazenar senhas com segurança.
Equívocos comuns vs. a verdade
Equívoco
- Um sal precisa ser mantido em segredo
- Um único sal compartilhado para todos os usuários serve
- Um sal torna até senhas fracas seguras
A verdade
- Um sal pode ser público (armazene-o com o hash)
- Um valor aleatório diferente por usuário (idealmente por senha)
- Um sal defende contra "pré-computação e quebra por reuso"; a força bruta é tratada por um hash lento
A visão deste site: acerte primeiro o sal e o hash lento
A pimenta (pepper) é uma medida extra para o caso em que só o banco de dados é roubado. Ela acrescenta o trabalho de gerenciar um segredo em outro lugar e, se você perder esse segredo, não consegue mais verificar a senha de ninguém.
Por isso, na prática, a primeira prioridade é usar sal + um hash lento corretamente via bcrypt/Argon2. Considere uma pimenta quando você já tiver uma estrutura de gerenciamento de chaves funcionando.
Fontes (primárias)
- NIST, "SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management" (agosto de 2025) — pages.nist.gov (sal de pelo menos 32 bits, armazenamento do sal e do hash, chave secreta armazenada separadamente)
- RFC 9106, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications" — rfc-editor.org (sal de 16 bytes recomendado para hashing de senhas)
- OWASP, "Password Storage Cheat Sheet" — cheatsheetseries.owasp.org (sal, pimenta, a maioria das bibliotecas trata o sal automaticamente)
- PHC string format (o formato de string de hash usado pelo Argon2 e outros) — github.com/P-H-C
- TechCrunch, "LinkedIn Confirms Hack And Leak Of 'Some' User Passwords" (6 de junho de 2012) — techcrunch.com (cerca de 6,5 milhões, declaração da empresa sobre a migração para hash com sal)
- Computerworld, "LinkedIn provides breach update -- sort of" (8 de junho de 2012) — computerworld.com (críticas ao hash só com SHA-1, senhas invalidadas)
Leia a seguir
- Glossário: o que é hashing de senha (entenda-o junto com o sal)
- Aprenda: como armazenar senhas com segurança (hashing + sal na prática)
- Fundamentos: armazenando senhas do jeito certo