Hash de senhas
Por que senhas nunca são guardadas, nem criptografadas, e quais algoritmos resistem a um vazamento do banco.
Quatro algoritmos são aceitos para senhas hoje. A escolha entre eles importa menos do que usar um deles com parâmetros adequados e manter esses parâmetros atualizados.
Os quatro algoritmos
| Algoritmo | Ano | Usa muita memória | Situação |
|---|---|---|---|
| Argon2id | 2015 | Sim, configurável | Primeira escolha; venceu a competição de hash de senhas |
| scrypt | 2009 | Sim, configurável | Boa alternativa quando Argon2 não está disponível |
| bcrypt | 1999 | Pouca (4 KB) | Ainda seguro e muito difundido; tem limite de 72 bytes |
| PBKDF2 | 2000 | Não | Aceitável quando há exigência de certificação (FIPS) |
A diferença principal está na memória. Quanto mais memória cada tentativa exige, menos tentativas uma placa de vídeo ou um chip dedicado consegue fazer em paralelo. Por isso Argon2id e scrypt resistem melhor a ataques com hardware especializado.
Parâmetros recomendados
Valores mínimos recomendados pela OWASP para cada algoritmo:
| Algoritmo | Parâmetros mínimos |
|---|---|
| Argon2id | 19 MiB de memória, 2 iterações, paralelismo 1 |
| scrypt | N = 2^17, r = 8, p = 1 |
| bcrypt | Custo 10 (prefira 12 se o servidor aguentar) |
| PBKDF2-HMAC-SHA256 | 600.000 iterações |
O limite de 72 bytes do bcrypt
O bcrypt ignora tudo depois do 72º byte da senha. Com caracteres acentuados ou emojis, que ocupam vários bytes, o limite chega antes de 72 caracteres. Duas senhas longas que começam iguais passam a ser aceitas uma pela outra.
As saídas são limitar o tamanho da senha antes do hash, deixar a biblioteca recusar senhas longas demais (algumas fazem isso) ou escolher Argon2id. Evite a "correção" de aplicar SHA-256 antes do bcrypt sem codificar o resultado: o hash binário pode conter bytes nulos, e algumas implementações param de ler no primeiro deles.
Como escolher o custo
O custo é uma troca entre segurança e capacidade do servidor.
| Custo alto | Custo baixo | |
|---|---|---|
| Tentativas por segundo do atacante | Poucas | Muitas |
| Tempo de login | Perceptível acima de ~500 ms | Imperceptível |
| CPU e memória por login | Altas | Baixas |
| Risco de sobrecarga | Uma onda de logins pode derrubar o serviço | Baixo |
Um procedimento prático:
- Comece pelos valores mínimos da tabela anterior.
- Meça o tempo de um hash no servidor de produção. Mire entre 100 e 500 ms.
- Calcule a memória: com Argon2id a 19 MiB, 50 logins simultâneos ocupam quase 1 GB.
- Coloque um limite de tentativas na rota de login. Sem ele, o custo do hash vira uma ferramenta de negação de serviço contra você.
Migrar hashes antigos
Sistemas antigos costumam ter senhas em MD5, SHA-1 ou bcrypt com custo baixo. Como não dá para recalcular sem a senha original, há duas estratégias.
| Estratégia | Como funciona | Vantagem | Limite |
|---|---|---|---|
| Refazer no login | Ao fazer login, a senha digitada é conferida com o hash antigo e regravada com o novo algoritmo | Simples, sem tocar em todos os registros | Quem não entra nunca fica com o hash fraco |
| Envolver o hash antigo | Aplica o algoritmo novo sobre o hash antigo de todos os usuários de uma vez: argon2id(md5(senha)) | Protege todos imediatamente | Exige conferir o formato no login até cada usuário ser migrado |
O caminho mais seguro combina as duas: envolver tudo agora e refazer com o formato limpo no próximo login. Contas que não entram há muito tempo podem ter a senha invalidada, com recuperação por e-mail.
O que vem antes e depois do hash
Um bom hash protege senhas depois de um vazamento. Outras decisões reduzem o estrago antes disso.
| Prática | O que fazer |
|---|---|
| Política de senha | Mínimo de 8 caracteres (15 sem segundo fator), aceitar até 64 ou mais, aceitar qualquer caractere. Sem regras de composição obrigatória e sem troca periódica forçada, como recomenda o NIST |
| Senhas vazadas | Recusar senhas que aparecem em vazamentos conhecidos. O serviço Have I Been Pwned permite consultar sem enviar a senha |
| Limite de tentativas | Por conta e por endereço, com atraso crescente |
| Segundo fator | Torna inútil uma senha descoberta |
| Chaves de acesso (passkeys) | Eliminam a senha: o servidor guarda só uma chave pública |
Resumo da decisão
- Algoritmo: Argon2id; bcrypt ou scrypt quando for o que a plataforma oferece.
- Custo: os mínimos atuais da OWASP, medidos no seu servidor, com limite de tentativas na rota.
- Formato: a string completa da biblioteca, com algoritmo, parâmetros e sal.
- Evolução: refazer o hash no login sempre que os parâmetros mudarem.
- Legado: envolver os hashes fracos de uma vez e migrar no login.
O próximo nível mostra o cadastro, o login e a atualização de hash nas cinco linguagens.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Escolher algoritmo e parâmetros
Preciso escolher o algoritmo e os parâmetros de hash de senha do meu sistema. Faça estas perguntas, uma por vez, e espere as respostas: - Qual linguagem e framework eu uso, e o que eles oferecem por padrão? - Quanta CPU e memória tem o servidor que atende o login? - Qual é o pico esperado de logins simultâneos? - Existe exigência de certificação, como FIPS? Com as respostas, compare Argon2id, scrypt, bcrypt e PBKDF2 para o meu caso, incluindo a limitação de 72 bytes do bcrypt. Depois me ajude a escolher os parâmetros: explique como medir o tempo de um hash no meu servidor, calcule o consumo de memória no pico de logins e diga qual limite de tentativas a rota de login precisa ter para o custo do hash não virar uma forma de derrubar o serviço. Sempre que citar valores recomendados, diga de onde vêm e recomende que eu confirme a versão atual do guia da OWASP.
Migrar senhas de um sistema legado
Tenho um sistema com senhas guardadas de forma fraca e preciso migrar sem obrigar todos os usuários a trocar de senha. Pergunte primeiro como as senhas estão guardadas hoje (MD5, SHA-1, SHA-256 com ou sem sal, bcrypt com custo baixo), quantos usuários existem e quantos fazem login com frequência. Depois compare as estratégias: 1. Refazer o hash no próximo login. 2. Envolver os hashes antigos com o algoritmo novo, de uma vez. 3. A combinação das duas. 4. Invalidar as senhas e forçar a recuperação. Para a estratégia recomendada, mostre o formato de armazenamento durante a transição, a lógica do login que reconhece cada formato e a forma de acompanhar quantos usuários ainda estão no formato antigo. Aponte os erros mais comuns nesse tipo de migração e como evitá-los.
Política de senhas que ajuda de verdade
Quero definir a política de senhas do meu sistema com base no que realmente reduz risco, e não no costume. Explique as recomendações atuais do NIST sobre tamanho mínimo e máximo, caracteres permitidos, regras de composição, troca periódica e verificação contra senhas vazadas. Para cada recomendação, explique o motivo e o comportamento dos usuários que ela leva em conta. Depois, explique como consultar senhas vazadas sem enviar a senha a um serviço externo, usando a técnica de anonimato por prefixo do Have I Been Pwned. Por fim, compare a senha com segundo fator e com chaves de acesso (passkeys), e diga em que situações vale a pena oferecer cada opção. Pergunte qual é o tipo de sistema e de usuário antes de recomendar uma política final.