# Como guardar senha de usuário: hash lento, sal e pimenta

<https://unifokal.com/blog/como-guardar-senha-de-usuario>

Guia · UNIFOKAL · 24 de outubro de 2026 · 6 min de leitura · Produto e integração

O que a OWASP e a NIST SP 800-63B-4 pedem para guardar senha: função de hash lenta, sal único, custo calibrado, pimenta fora do banco e um caminho para trocar o algoritmo depois.

O banco de senhas é o que o atacante leva quando invade o sistema, e o que ele faz depois depende só de como as senhas foram guardadas: em texto puro ou cifradas, ele lê tudo; com hash rápido, ele testa bilhões de palpites por segundo. A resposta curta: a senha é guardada com uma função de hash lenta e feita para senha, com sal único por senha, como manda a NIST SP 800-63B-4, e a OWASP indica o Argon2id como primeira escolha, o scrypt quando ele não existe, e uma pimenta guardada fora do banco como defesa a mais.

**Em resumo**

- A NIST SP 800-63B-4 manda que as senhas sejam "salted and hashed using a suitable password hashing scheme", com sal de pelo menos 32 bits.
- A OWASP recomenda Argon2id; sem ele, scrypt; bcrypt para sistema legado; PBKDF2 quando há exigência FIPS-140.
- Hash rápido, como SHA-256 puro, não serve: ele deixa o atacante testar palpites rápido demais.
- A pimenta é um segredo único, guardado fora do banco, e trocá-la exige que cada pessoa redefina a senha.
- O formato guardado registra o algoritmo e o custo, para o sistema subir o custo no login seguinte.

## Hash, não cifra

A diferença entre hash e cifra decide o resto. A cifra tem volta: quem tem a chave lê a senha. O hash não tem volta: o sistema guarda o resultado e, no login, calcula de novo e compara. A Password Storage Cheat Sheet da OWASP é direta: senhas devem ser guardadas com algoritmos de hash modernos e adaptativos, "rather than encrypted or stored in plaintext". A cifra só aparece no caso raro de o sistema precisar da senha original para entrar em outro sistema, e a própria OWASP recomenda evitar essa arquitetura.

A NIST SP 800-63B-4 diz o mesmo na seção 3.1.1.2, a dos verificadores de senha.

> Verifiers SHALL store passwords in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using a suitable password hashing scheme. Password hashing schemes take a password, a salt, and a cost factor as inputs and generate a password hash.
>
> NIST SP 800-63B-4, seção 3.1.1.2

A palavra que importa é "offline". O ataque que o armazenamento precisa aguentar não é o login, que tem limite de tentativas; é o atacante com o banco copiado na máquina dele, testando palpites sem limite. Contra esse ataque, só o custo de cada palpite ajuda.

## Qual função usar

**as funções de hash de senha e as configurações mínimas da OWASP Password Storage Cheat Sheet**

| Função | Quando usar | Configuração mínima indicada |
|---|---|---|
| Argon2id | Primeira escolha | 19 MiB de memória, 2 iterações, paralelismo 1 (ou outra das configurações equivalentes da lista) |
| scrypt | Quando o Argon2id não está disponível | N=2^17, r=8, p=1 (ou equivalente, como N=2^16, r=8, p=2) |
| bcrypt | Sistema legado | Fator de trabalho 10 ou mais, senha limitada a 72 bytes |
| PBKDF2 | Quando há exigência FIPS-140 | 600.000 iterações com HMAC-SHA-256 |

O que essas funções têm em comum é ser lentas de propósito, e o Argon2id e o scrypt também gastam memória, o que encarece o ataque com placa de vídeo. A OWASP lembra que as configurações de cada linha dão defesa equivalente: o que muda é a troca entre processador e memória.

> **Atenção**
>
> O limite de 72 bytes do bcrypt corta a senha longa em silêncio na maioria das implementações. Se o sistema aceita frase longa, como pede a NIST, e usa bcrypt, os caracteres além do limite não contam. É mais um motivo para preferir Argon2id ou scrypt em sistema novo.

## Sal e custo

O sal é um valor aleatório, diferente para cada senha, guardado junto com o hash. Ele faz duas coisas, segundo a OWASP: obriga o atacante a quebrar uma senha de cada vez, e impede saber se duas pessoas têm a mesma senha. A NIST pede, na mesma seção 3.1.1.2, sal de pelo menos 32 bits, escolhido para evitar colisão. As bibliotecas modernas geram o sal sozinhas; o erro é reaproveitar um sal fixo para todo mundo.

O custo é o parâmetro que torna a função lenta. A OWASP diz que não há regra de ouro, que o valor depende do servidor e do número de usuários, e dá uma referência: calcular o hash deve levar menos de um segundo. Há um risco do outro lado: custo alto demais transforma o login num alvo de negação de serviço, porque cada tentativa consome processador e memória. O limite de tentativas no login é o que segura esse lado, como discute o artigo sobre [força bruta e credential stuffing](https://unifokal.com/blog/forca-bruta-e-credential-stuffing).

## Pimenta e troca de algoritmo

A pimenta é um segredo único do sistema, guardado fora do banco de senhas, por exemplo num cofre de segredos. A OWASP descreve duas formas de aplicá-la e recomenda tratá-la como defesa a mais, que sozinha não dá segurança. Na forma pós-hash, o resultado da função lenta passa por um HMAC com a pimenta como chave antes de ir ao banco. Se o atacante leva só o banco, sem a pimenta, os hashes não servem para testar palpites. A NIST SP 800-63B-4 também recomenda, na seção 3.1.1.2, uma etapa adicional com chave secreta guardada à parte.

O preço da pimenta é a troca. A OWASP avisa: a pimenta não muda sem a senha da pessoa, então trocar a pimenta exige "forcing all users whose passwords were protected by the previous pepper to reset their passwords". Guarde junto do hash qual versão da pimenta o protegeu, para a troca poder ser gradual.

O mesmo vale para o algoritmo. A OWASP recomenda guardar o algoritmo e o custo junto do hash, num formato padrão, e refazer o hash com a configuração nova no próximo login de cada pessoa, quando a senha está disponível. Quem não volta fica com o hash antigo; para esses, a OWASP sugere expirar a senha e pedir redefinição. A lista que impede a senha fraca antes de ela chegar ao hash está em [senha vazada](https://unifokal.com/blog/senha-vazada-como-bloquear-no-cadastro-e-no-login).

## Perguntas frequentes

### Posso guardar senha com SHA-256 e sal?

Não é recomendado. A OWASP diz que hashes rápidos como SHA-256 não servem para senha, porque permitem testar palpites rápido demais. A senha pede uma função lenta e feita para isso, como Argon2id ou scrypt.

### Senha deve ser cifrada ou passar por hash?

Passar por hash. A cifra tem volta, e quem tem a chave lê todas as senhas. A NIST SP 800-63B-4 manda guardar a senha com sal e uma função de hash de senha adequada.

### O que é pimenta em armazenamento de senha?

É um segredo do sistema guardado fora do banco de senhas e aplicado a todos os hashes. Se o banco vaza sem a pimenta, os hashes não servem para testar palpites. Trocá-la exige que as pessoas redefinam a senha.

### Como migrar de um algoritmo antigo sem pedir a senha de todo mundo?

Refazendo o hash com o algoritmo novo no próximo login de cada pessoa, quando a senha está disponível, e guardando o algoritmo e o custo junto do hash. Para quem não volta, a OWASP sugere expirar a senha e pedir redefinição.

## Fontes citadas

- OWASP, Password Storage Cheat Sheet, no [repositório oficial](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md)
- NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, seção 3.1.1.2 (verificadores de senha), em [pages.nist.gov](https://pages.nist.gov/800-63-4/sp800-63b.html)