O que é "salting" em segurança? Hashing de senhas explicado.

Em junho de 2012, um invasor vazou 117 milhões de registros de contas do LinkedIn em um fórum russo. A lista era uma avalanche de hashes SHA-1 sem salt. O SHA-1 é rápido. Sem um salt para quebrar senhas idênticas, o mesmo hash aparecia milhares de vezes ao lado do mesmo hash. Em aproximadamente 72 horas, pesquisadores de segurança haviam decifrado cerca de 90% do arquivo. Quando a violação ressurgiu em maio de 2016 como parte de um conjunto de dados com 167 milhões de registros, essas credenciais alimentaram campanhas de credential stuffing por anos.

A defesa que teria minimizado essa violação — adicionar um "sal" a cada senha armazenada — já existia em 1979. Chama-se "salting". Não é nova, não é cara e não é particularmente engenhosa. É a diferença entre um vazamento de banco de dados ser um incidente isolado e se tornar o problema de senhas de todos por meia década.

A maioria das falhas modernas em sistemas de armazenamento de senhas ainda tem a mesma causa raiz: alguém decidiu que "usamos SHA-256" era suficiente. Este artigo explica o que é o salting, como funciona na prática, contra o que protege e contra o que não protege, e qual é a recomendação da OWASP como padrão para 2026.

O que é "salting" em segurança e hash de senhas?

Resumindo o assunto em uma frase: "Salt" significa adicionar dados aleatórios a uma senha antes que ela seja criptografada (hash). O valor aleatório — o salt — é gerado uma única vez por conta, juntamente com o novo hash da senha, armazenado em texto simples ao lado do hash resultante e lido a cada login. Não é uma chave. Não é um segredo. Não é criptografia. É um modificador público com uma única função: garantir que, quando dois usuários tiverem a mesma senha, eles nunca compartilhem o mesmo hash armazenado.

O hashing por si só é unidirecional. Ao aplicar um hashing a uma senha usando SHA-256 ou Argon2id, você obtém um valor de comprimento fixo que nenhum algoritmo consegue reverter. A questão é que "nenhum algoritmo" exclui um atalho fácil: consultar o hash em um dicionário pré-computado. O uso de um salt elimina esse atalho. Adicionar um salt ao processo de hashing cria um hash único para cada usuário, mesmo quando o texto da senha subjacente é idêntico palavra por palavra. Senhas comuns como "password" e "qwerty" não entram mais em conflito no banco de dados. O uso de um salt garante que o vazamento de uma linha não revele nada ao atacante sobre os outros usuários.

Três regras separam um salt utilizável de um inútil. Primeira regra: cada senha recebe seu próprio salt aleatório, gerado imediatamente após o cadastro ou a redefinição da senha pelo usuário. Uma senha com salt reutilizada em diferentes contas é pouco melhor do que uma senha sem salt — o ataque em massa funciona da mesma maneira. Segunda regra: o salt pode ser público. Conhecer o salt por si só não oferece ao atacante nenhuma vantagem contra a função hash subjacente. Portanto, o salt reside no banco de dados junto com o hash, e essa localização é aceitável, até mesmo recomendada. Terceira regra: os valores do salt são gerados por um gerador de números pseudoaleatórios criptograficamente seguro. O Linux disponibiliza um através de `getrandom(2)`. O Node.js o chama de `crypto.randomBytes`. A biblioteca padrão do Python o encapsula em `secrets.token_bytes`. O método não criptográfico `Math.random()` é inadequado, embora apareça em código auditado com muito mais frequência do que deveria.

Duas pessoas que escolhem "hunter2" como senha devem ter dois hashes armazenados completamente diferentes. O salt é o que garante isso. Se o salt for omitido, o banco de dados vaza não apenas os hashes, mas também o grafo social de quem compartilha qual senha com quem.

Como funciona o salting de senhas?

O mecanismo se divide em quatro etapas, e dez anos de violações de segurança de senhas mostram que quase todas as falhas ocorrem porque alguém pulou uma delas.

A primeira etapa é executada no momento do registro. O aplicativo solicita a um gerador de números aleatórios CSPRNG de dezesseis a trinta e dois bytes aleatórios. Esse é o salt. As diretrizes da OWASP para 2025 consideram dezesseis bytes (128 bits) como o mínimo; a auth0 e vários fornecedores de gerenciadores de senhas recomendam o uso de trinta e dois bytes. O documento SP 800-63B-4 do NIST define um mínimo de quatro bytes, mas alerta que colisões relacionadas à data de aniversário começam a aparecer por volta de sessenta e cinco mil usuários com esse tamanho, razão pela qual ninguém usa quatro bytes na prática.

A segunda etapa combina o salt com a senha escolhida pelo usuário. A concatenação é a forma mais comum, com o salt colocado antes ou depois da sequência da senha. Alguns sistemas usam HMAC em vez disso, tratando o salt como a chave HMAC, o que evita alguns problemas obscuros de extensão de comprimento que ocorrem com a concatenação direta.

A terceira etapa executa a entrada combinada por meio de um algoritmo de hash de senha — o que os livros de criptografia chamam de função de derivação de chave, ou KDF. Esta é a etapa em que a maioria das equipes costumava falhar, frequentemente optando por um algoritmo de hash genérico e considerando o trabalho concluído. O SHA-256 puro é inadequado como forma de armazenar senhas por si só. Uma GPU de consumo em 2026 processa mais de cem bilhões de hashes SHA-256 por segundo, portanto, mesmo com um salt, o custo por tentativa em hash criptográfico permanece trivial. O uso de salt elimina vetores de ataque de tabela arco-íris. Ele não retarda a quebra de senhas por força bruta por si só. A ferramenta correta aqui é uma função deliberadamente lenta e com uso intensivo de memória: Argon2id é o padrão preferido pela OWASP, com scrypt e bcrypt aceitáveis, e PBKDF2 com contagens de iterações muito altas permitidas onde a conformidade com FIPS-140 força a escolha.

A quarta etapa armazena tanto o hash quanto o salt. Bibliotecas modernas cuidam do formato de armazenamento, então você não precisa gerenciar o salt manualmente. A saída do bcrypt se parece com `$2b$12$9f4c8a7b...kQR8YZpL9` — essa única string contém o identificador do algoritmo, o fator de custo, o salt e o valor do hash. O Argon2id usa o formato de string PHC análogo, `$argon2id$v=19$m=19456,t=2,p=1$$`. Você grava essa string em uma coluna do banco de dados e pronto. A biblioteca já fez tudo o que é necessário para armazenar senhas com segurança — gerou dados aleatórios para o salt, executou a senha em um algoritmo de hash lento e agrupou o resultado para recuperação.

O login segue o mesmo fluxo inverso. O aplicativo busca o salt e o hash armazenado do usuário, executa a senha enviada pelo mesmo algoritmo com o mesmo salt e compara o resultado com o hash armazenado usando uma comparação de tempo constante. O tempo constante é importante: um simples `==` vaza informações sobre quantos bytes corresponderam, o que já gerou vulnerabilidades reais em ataques de temporização. Use `hmac.compare_digest`, `crypto.timingSafeEqual` ou o equivalente em seu framework.

Por que o sal é importante: o problema da mesa arco-íris

As tabelas rainbow são o tipo específico de ataque que o salting foi inventado para combater. Imagine uma tabela de consulta pré-computada que mapeia todas as senhas plausíveis — cada palavra do dicionário, variação comum, entrada de lista vazada — para seu hash SHA-256. Essas tabelas existem, são vendidas em fóruns de crackers e chegam a terabytes. Uma vez que um atacante possui um dump de um banco de dados com hashes sem salting, buscar um hash em uma tabela rainbow se torna uma consulta ao banco de dados, não uma tarefa de quebra de senhas. O ataque ao LinkedIn em 2012 ocorreu exatamente dessa forma: 117 milhões de hashes SHA-1 sem salting foram testados em uma tabela rainbow, 90% dos quais foram quebrados em aproximadamente três dias.

Adicionar um salt por usuário faz com que as tabelas rainbow parem de funcionar. O atacante precisaria de uma tabela pré-computada separada para cada valor de salt único. Com um salt aleatório de dezesseis bytes, isso significa 117 milhões de tabelas diferentes para 117 milhões de usuários — e cada tabela ainda teria terabytes de tamanho. Só os custos de armazenamento tornam isso inviável. O ataque sai do modelo de ameaça.

Essa é exatamente a função de um salt. Ele é propositalmente específico. O uso de salt não impede uma tentativa de força bruta determinada contra um usuário específico. O uso de salt não impede o preenchimento de credenciais vazadas anteriormente. O uso de salt não ajuda se a própria senha for "123456" — o atacante tenta o dicionário óbvio, e o salt é recalculado para cada tentativa, mas não altera significativamente o custo por tentativa.

O que o uso de salt mitiga de forma confiável: tabelas rainbow e o vazamento de informações de reutilização de senhas entre usuários no mesmo banco de dados. O que o hash lento mitiga: o custo por tentativa. O que o pepper mitiga: roubo exclusivo do banco de dados. O que a autenticação multifator (MFA) mitiga: ataques de preenchimento de credenciais. O uso de salt é uma camada de segurança em uma pilha — adicionar um salt para dificultar a quebra de senhas não é o mesmo que tornar cada senha individualmente difícil de adivinhar. O objetivo do uso de salt é fornecer um hash diferente para cada usuário; tornar cada tentativa custosa é um problema à parte.

Hashing vs criptografia vs salting

Três termos que costumam ser confundidos, especialmente em textos escritos por não especialistas. Eles não são intercambiáveis.

A criptografia protege os dados que você deseja recuperar posteriormente. O destinatário possui a chave, aplica-a e lê o original. O hashing é unidirecional: uma vez que uma senha se torna um hash, nenhum algoritmo a reverte. O salting é um modificador que você aplica à entrada de uma função hash — ele não tem significado por si só.

A violação de segurança da Adobe em 2013 serve como um exemplo de alerta. A Adobe armazenava 153 milhões de registros de usuários criptografando senhas com 3DES no modo ECB, usando uma única chave para todo o site. Essa escolha foi um fracasso triplo. A criptografia é o método inadequado para armazenamento de senhas. O modo ECB permite o vazamento de entradas idênticas, já que as saídas também são idênticas. Reutilizar uma única chave em todo o banco de dados significava que decodificar a chave uma única vez decodificava todos os 153 milhões de registros. Schneier classificou o incidente como uma das piores violações de senhas da história. A solução em todas as camadas foi a adoção de hashing lento com salt.

Sal versus pimenta: a defesa em duas camadas

A pimenta é a prima menos conhecida do sal. O conceito: um valor secreto adicional, aplicado a cada senha processada pelo aplicativo, mas armazenado fora do banco de dados. Uma variável de ambiente, uma entrada de serviço de gerenciamento de chaves ou uma chave residente em um HSM. O sal reside ao lado do hash em texto simples. A pimenta não.

O modelo de ameaça é o roubo exclusivo do banco de dados. Se um atacante roubar apenas o banco de dados — por meio de injeção de SQL, um backup mal configurado ou um dump vazado — ele terá os salts e hashes, mas não o pepper. Sem o pepper, ele não consegue nem começar um ataque de força bruta, porque cada tentativa de hash não inclui o modificador secreto global.

Uma implementação típica executa `argon2id(salt + password + pepper)` ou, mais cuidadosamente, calcula primeiro `HMAC(pepper, password + salt)` e alimenta o resultado no Argon2id. A OWASP recomenda o uso de pepper para sistemas de alto valor, mas reconhece a desvantagem: a rotação do pepper é operacionalmente complexa. Rotacioná-lo significa gerar um novo hash da senha de cada usuário no próximo login e, se o pepper for perdido sem um backup, todas as contas se tornam inverificáveis. A maioria dos aplicativos de consumo dispensa o uso de pepper. Já os sistemas bancários, governamentais e de saúde geralmente o utilizam.

Criptografia de senhas moderna em 2026

As diretrizes da OWASP para armazenamento de senhas em 2025 classificam quatro algoritmos em ordem de preferência. O salt já está integrado em todos eles — você não precisa gerá-lo manualmente.

O Argon2id é altamente exigente em termos de memória, o que significa que cada tentativa custa não apenas ciclos de CPU, mas também uma quantidade definida de RAM. O mínimo de 19 MiB por hash, definido pela OWASP, implica que um atacante que construa um ASIC personalizado também precisaria de muita memória rápida, e a memória é o componente mais caro de qualquer sistema de ataque. A variante "id" combina o Argon2i (resistente a ataques de canal lateral) e o Argon2d (resistente a GPUs), executando o Argon2i na primeira metade e o Argon2d na segunda.

O scrypt é anterior ao Argon2id e funciona com o mesmo princípio de uso intensivo de memória. O bcrypt é ainda mais antigo, mais simples e tem um limite rígido de entrada de 72 bytes que ocasionalmente causa problemas em aplicações que usam senhas longas — pré-hash com SHA-256 e codificação em base64 se precisar de entradas mais longas. O PBKDF2 é a opção mais lenta, porém compatível com FIPS; a OWASP aumentou o número de iterações para 600.000 para o SHA-256 em 2023, ante as 310.000 anteriores.

O que não pertence a esta lista: SHA-256 puro, SHA-512 puro, MD5, SHA-1 e qualquer função personalizada que termine com "+ salt". A velocidade é o fator de desqualificação. O SHA-256 foi projetado para ser rápido em hardware comum. Isso é o oposto do que o armazenamento de senhas precisa.

Erros comuns de salgamento que aparecem em auditorias reais

Os relatórios de violações de segurança no mundo real continuam a apontar sempre os mesmos poucos erros.

Reutilizar um mesmo salt para cada usuário anula todo o mecanismo — o problema da tabela arco-íris retorna, apenas com uma etapa extra. Usar o nome de usuário como salt é pior, porque os nomes de usuário se repetem em diferentes sistemas e as tabelas arco-íris podem ser pré-computadas para os mais populares. Salts com menos de dezesseis bytes começam a admitir colisões na escala de grandes bases de usuários. Gerar um salt com uma função aleatória não criptográfica — `Math.random()`, `time(0)` mod alguma coisa, o gerador de números aleatórios padrão da linguagem — produz valores previsíveis que eliminam a vantagem do uso de salt.

Um erro mais sutil é armazenar o salt em um servidor diferente "por segurança". O salt não é um segredo. Dividi-lo entre sistemas diferentes aumenta a complexidade operacional sem adicionar qualquer força criptográfica. Armazene-o na mesma linha que o hash. As strings PHC modernas fazem isso automaticamente.

O maior problema, previsto para auditorias de 2026, é o uso de hashing com SHA-256 puro, além de um salt e um método de envio. O salt impede a criação de tabelas rainbow. Ele não impede que uma fazenda de GPUs execute dez bilhões de tentativas por segundo contra uma única conta. A solução não é adicionar um segundo salt, mas sim migrar para um KDF mais lento, como o Argon2id.

Por último: hashes legados sem salt. A migração não é opcional. O padrão é verificar o hash legado no próximo login, gerar um novo hash com o algoritmo moderno e sobrescrevê-lo. Para usuários que nunca mais fizerem login, force uma redefinição de senha em um período fixo.

Por que salgar sozinho não é suficiente

O uso de sal é uma camada de segurança, não uma fortaleza. Ele neutraliza um ataque específico — tabelas pré-computadas — e não revela nada sobre a força da senha subjacente. Ataques de força bruta ainda funcionam contra senhas fracas. Ataques de preenchimento de credenciais ainda funcionam contra senhas reutilizadas. Phishing ainda funciona contra qualquer senha.

A verdadeira segurança de senhas em 2026 utiliza quatro defesas. O Argon2id, com um salt de dezesseis bytes por usuário, gerencia o armazenamento. Um pepper, opcional, mas útil para sistemas sensíveis, bloqueia o roubo exclusivo do banco de dados. A autenticação multifator impede ataques de preenchimento de credenciais e a maioria dos ataques de phishing. O monitoramento contínuo de violações — serviços como o Have I Been Pwned e sua API — detecta o momento exato em que as credenciais de um usuário aparecem em um vazamento, permitindo que ele seja forçado a redefini-las.

Ignore qualquer uma dessas camadas e um invasor eventualmente encontrará a brecha. O uso de "salt" isoladamente, ou qualquer uma dessas defesas isoladamente, é exatamente o que todas as análises pós-invasão de segurança da última década identificaram como o ponto de falha.

Jordan Morris

Jordan Morris is an AI expert with over a decade of experience and the author of a widely-read blog focused on artificial intelligence. His content spans a range of topics—from the ethics of machine learning to real-world applications of neural networks in business. Known for his clear writing and deep insights, Jordan has become a trusted voice in the AI community, appealing to both newcomers and seasoned professionals alike.