# Como hashing, salting e peppering protegem senhas?

> Published 2026-10-11T13:57:03.612Z on https://www.crazystack.com.br/pt/p/como-hashing-salting-e-peppering-protegem-senhas/
> Source video: https://www.youtube.com/watch?v=SZb7yyhTWBg

Armazenar senha em texto puro está errado em todas as circunstâncias, mas só isso não basta: hashing, salting e peppering formam a combinação mínima aceitável. Muitos sistemas ainda usam criptografia antiga ou guardam senhas cruas, e é exatamente esse erro que este guia existe para evitar.

## Hashing, salting e peppering: como armazenar senhas do jeito certo

Para armazenar senhas com segurança, você combina três conceitos: hashing, salting e peppering. O hash torna a senha irrecuperável, o salt torna cada hash único e o pepper adiciona um segredo guardado fora do banco de dados. Nunca armazene a senha em texto puro; esse é o erro mais grave possível em autenticação.

Este artigo é uma introdução ao armazenamento de senhas, baseada na aula do canal do Augusto Galego. O objetivo não é transformar você em especialista em criptografia, e sim impedir erros monumentais: senha em texto puro, criptografia antiga ou funções de hash rápidas demais.

## Quais são as ameaças: ataque online e ataque offline

Existem dois modelos de ameaça, e cada um pede defesas diferentes. Entender essa separação evita que você invista na camada errada.

### Ataque online

No ataque online, o invasor testa senhas uma atrás da outra no próprio formulário de login até acertar. Contra isso, hashing e salt não ajudam muito: o que bloqueia é infraestrutura na frente da aplicação.

- **Rate limit**: limite tentativas por IP, por dispositivo e por usuário, como os sistemas que travam o login após cinco erros seguidos.
- **Controle de requisições paralelas**: impeça que um mesmo cliente dispare milhares de tentativas simultâneas.
- **MFA**: exija o código do autenticador, de e-mail ou de WhatsApp depois da senha correta.

Com rate limit, trava de conta e autenticação de múltiplos fatores bem configurados, o ataque online deixa de ser viável na esmagadora maioria dos casos.

## Hashing lento: por que Argon2id e não MD5

O ataque offline começa quando o invasor consegue o dump do banco de dados. Se as senhas estiverem cruas, ele tem a senha desse aplicativo e, como muita gente reutiliza senha, provavelmente a senha de vários outros serviços também.

A defesa é o hash: uma função de mão única que sempre produz o mesmo resultado para o mesmo input, mas não permite reverter o output para a senha original. Você armazena apenas o hash, não a senha.

O detalhe que quase todo mundo erra: para tabelas hash na sua linguagem de programação, você quer velocidade. Para senhas, você quer o oposto. A função deve ser deliberadamente lenta e pesada em memória, para tornar a força bruta cara. O [Argon2](https://github.com/P-H-C/phc-winner-argon2), vencedor da competição Password Hashing de 2015, é a família mais recomendada hoje, com a variante Argon2id como escolha padrão segundo o [guia da OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html).

O tamanho do espaço de senhas importa. Com apenas letras minúsculas e 8 caracteres, existem 26 elevado a 8 combinações. Adicione maiúsculas (52), dígitos (62) e símbolos, e o número cresce muito. Uma senha longa, com todas as classes de caracteres, contra um hash caro, tem tempo estimado de quebra medido em bilhões de anos com o poder computacional atual.

## Salting: o número aleatório que quebra tabelas pré-computadas

O hash resolve a força bruta, mas cria um problema novo: a mesma senha passada pela mesma função gera sempre o mesmo hash. Se Alice e Bob usam a senha "1234", os dois hashes serão idênticos, e um atacante com uma tabela pré-computada encontra a senha de olho, sem calcular nada.

A solução é o salt: um número aleatório, grande e único por usuário, gerado antes do hash. Bob recebe um salt, Alice recebe outro, e mesmo com senhas iguais os hashes finais ficam completamente diferentes.

Você pode armazenar o salt no próprio banco de dados, junto do hash, sem problema. Mesmo que o atacante roube os dois, as tabelas pré-computadas ficam inúteis, porque ele precisaria recalcular tudo para cada combinação específica de salt e senha.

Não invente a geração de salt na mão e nunca use um ID incremental como salt. As bibliotecas de hashing de senha já geram um salt único e aleatório automaticamente. As regras são simples: aleatório, grande e único por senha.

## Peppering: o segredo opcional que fica fora do banco

Suponha o pior cenário: o atacante tem o hash, o salt e sabe que você usa Argon2id. Ainda existe uma última camada, o pepper: um valor secreto, compartilhado por aplicação, que funciona como um segundo salt guardado fora do banco de dados.

A prática comum é armazená-lo em um secrets manager, como o [AWS Secrets Manager](https://aws.amazon.com/secretsmanager/) ou o equivalente da Google Cloud. Se o banco vazar, o pepper não vaza junto, e o atacante continua sem conseguir testar candidatos de senha.

O pepper é opcional e controverso, e a razão do risco é operacional. Se você perder esse valor em um deploy errado, invalida todas as senhas do aplicativo de uma vez: nenhum usuário faz login, e todo mundo precisa redefinir a senha. Com salt e hash na própria tabela, um erro grave é difícil; com um pepper mal gerenciado, você pode quebrar a produção para 100% dos usuários.

## Implementar ou terceirizar: três caminhos recomendados

Fazer tudo isso da maneira correta exige experiência e cuidado. Existem três caminhos sólidos, em ordem crescente de terceirização.

| Caminho | O que você faz | Quando faz sentido |
| --- | --- | --- |
| Biblioteca dedicada | Usa Argon2id com uma lib madura | Você quer controle e sabe seguir o padrão |
| Framework de auth | Delega hash, salt e sessões ao framework | Solo founder de SaaS que não quer errar |
| Identity provider | Terceiriza todo o login | Nível máximo de delegação |

No primeiro caminho, use uma biblioteca consagrada com [Argon2](https://github.com/P-H-C/phc-winner-argon2) e siga a documentação sem inventar variações. No segundo, um framework de nível mais alto como o [Better Auth](https://www.better-auth.com/) previne a maior parte dos deslizes, porque desenvolvedores, em geral, não são especialistas em segurança. No terceiro, um identity provider como o [Clerk](https://clerk.com), plataforma de autenticação e gestão de usuários, cuida de todo o fluxo de login; Amazon Cognito e Auth0 seguem na mesma categoria.

Existe ainda o caminho de eliminar a senha por completo: magic link por e-mail ou login social via Google e GitHub. Para muitos produtos B2C, essa é a escolha mais tranquila, porque remove toda a dor de cabeça do armazenamento. A recomendação final vale para qualquer um dos caminhos: audite o sistema que você tem em produção hoje e confirme se ele não guarda senha em texto puro nem usa um algoritmo antigo e quebrável.

## FAQ

- **O salt pode ficar no mesmo banco de dados que o hash?** Sim. O salt não precisa ser secreto, apenas aleatório, grande e único por usuário. Mesmo que o atacante o obtenha junto com o dump, as tabelas pré-computadas perdem a utilidade.

- **Argon2id é obrigatório?** Não é o único, mas é o mais recomendado atualmente pela OWASP. O essencial é usar uma função de hash lenta e intensiva em memória, projetada para senhas, e nunca uma função rápida como as de tabelas hash comuns.

- **Devo usar pepper no meu projeto?** É opcional. Ele adiciona proteção contra o vazamento completo do banco, mas introduz um risco operacional: perder o pepper invalida todas as senhas de uma vez. Use-o apenas com um secrets manager bem gerenciado.

- **Posso implementar hash e salt por conta própria?** Não invente seu próprio esquema. Use uma biblioteca consagrada de Argon2 e siga o padrão de mercado, ou delegue para um framework de autenticação ou um identity provider.

## Do vídeo ao artigo: o seu conteúdo também merece essa estrutura

A aula que originou este artigo, do canal do Gustavo Dev Doido parceiro nos materiais do [Crazystack Typescript](https://crazystack.com.br) e do Bootcamp do Dev Doido, explica hashing, salting e peppering em vinte minutos de conversa. Esse tipo de explicação, quando fica presa em vídeo, é difícil de citar, revisar e encontrar depois.

Se você também tem conhecimento valioso gravado em vídeos do YouTube, aulas, entrevistas ou análises técnicas, o [Skala Blog](https://skalablog.com) transforma esse material em artigo estruturado: você cola a URL, o vídeo é transcrito e o texto ganha formato publicável. O mesmo caminho que levou esta aula de segurança até esta página.

[Source video](https://www.youtube.com/watch?v=SZb7yyhTWBg)