Se você trabalha com segurança de aplicações, já deve ter ouvido dizer que “MD5 e SHA-256 não servem para armazenar senhas”. Isso é verdade, mas a pergunta que poucos sabem responder é: qual algoritmo usar no lugar? Hoje a resposta técnica correta, endossada pelo OWASP e pelo NIST, tem nome: Argon2, mais especificamente sua variante Argon2id.
Neste artigo vou explicar por que o Argon2 venceu a Password Hashing Competition, como ele funciona por dentro, e quais parâmetros usar em produção.
O problema que o Argon2 resolve
Funções de hash criptográfico “normais” como SHA-256 foram desenhadas para serem rápidas. Isso é ótimo para verificar a integridade de um arquivo, mas é péssimo para proteger senhas: um atacante com GPUs ou hardware dedicado (ASIC) consegue testar bilhões de combinações por segundo contra um hash rápido.
A resposta da indústria foi criar funções de hash deliberadamente lentas e “memory-hard” — ou seja, que exigem uma quantidade significativa de memória RAM para cada tentativa de hash, não só tempo de CPU. Isso encarece brutalmente ataques em paralelo, porque GPUs e ASICs têm memória por núcleo muito limitada em comparação com CPUs comuns.
O bcrypt (1999) e o PBKDF2 (2000) foram os pioneiros nessa filosofia, mas usam pouca memória (bcrypt tem uma pegada fixa de poucos KB), o que os deixa vulneráveis a ataques paralelizados em hardware moderno. O scrypt (2009) melhorou isso ao introduzir memory-hardness real. O Argon2 é a evolução direta dessa linhagem, incorporando anos adicionais de criptoanálise.
Um pouco de história
O Argon2 foi desenvolvido por Alex Biryukov, Daniel Dinu e Dmitry Khovratovich e venceu a Password Hashing Competition (PHC) de 2015, uma competição aberta e pública nos moldes do processo que o NIST usa para selecionar algoritmos criptográficos. Em 2021 o algoritmo foi padronizado formalmente como RFC 9106.
As três variantes do Argon2
O Argon2 não é um algoritmo único, mas uma família com três variantes:
- Argon2d — usa acesso à memória dependente dos dados de entrada. É o mais resistente a ataques com GPU, mas isso o torna vulnerável a ataques de canal lateral (side-channel), já que o padrão de acesso à memória pode vazar informação sobre os dados processados.
- Argon2i — usa acesso à memória independente dos dados, o que o protege contra ataques de canal lateral, mas o deixa um pouco mais fraco contra ataques de força bruta com GPU.
- Argon2id — um híbrido: processa a primeira metade das iterações no modo Argon2i (resistente a canal lateral) e o restante no modo Argon2d (resistente a GPU). É o modo recomendado para praticamente todo caso de uso de autenticação, e é o que o OWASP recomenda como padrão.
Na prática: a menos que você tenha um motivo técnico muito específico, use sempre Argon2id.
Os três parâmetros que você precisa entender
Diferente do bcrypt, que tem só um “fator de custo”, o Argon2 expõe três parâmetros independentes, o que dá muito mais controle — e também mais chance de errar a configuração:
| Parâmetro | O que controla | Efeito ao aumentar |
|---|---|---|
| m (memory cost) | Quantidade de memória RAM usada por hash, em KiB | Encarece ataques com GPU/ASIC, que têm memória limitada por núcleo |
| t (time cost) | Número de iterações/passadas sobre a memória | Aumenta o tempo total de computação |
| p (parallelism) | Número de threads/lanes paralelas | Permite usar múltiplos núcleos de CPU no servidor legítimo |
O objetivo é calibrar esses três valores para que o hash de uma senha legítima demore uma fração de segundo aceitável no seu servidor, enquanto um atacante tentando testar bilhões de senhas continua praticamente inviabilizado pelo custo de memória.
Quais parâmetros usar hoje
O OWASP Password Storage Cheat Sheet recomenda, como configuração mínima para Argon2id: memória de 19 MiB, contagem de iterações de 2 e grau de paralelismo 1. Esse é o piso de segurança aceitável — se o seu servidor tem folga de CPU e memória, vale a pena aumentar esses valores e medir o tempo de resposta resultante, buscando algo entre 100ms e algumas centenas de milissegundos por verificação, dependendo da sua tolerância de UX.
Uma boa prática é fazer o benchmark no seu próprio hardware de produção em vez de copiar um número de um blog: rode a função de hash com parâmetros crescentes até atingir o tempo-alvo que você definiu, e documente essa decisão. Reavalie os parâmetros periodicamente — o poder de processamento disponível para um atacante só cresce com o tempo.
Se você quiser ver isso na prática sem escrever código, o argon2.online é um gerador e verificador de hash Argon2 direto no navegador — dá para testar os três parâmetros (memória, iterações, paralelismo) e ver o hash resultante em tempo real. Vale reforçar: não é o site oficial do algoritmo (esse é o repositório do projeto no GitHub), mas é uma ferramenta prática para quem quer entender o efeito de cada parâmetro antes de configurar isso em produção.
Exemplo de implementação (Node.js)
javascript
import * as argon2 from "argon2";
async function hashPassword(senhaEmTextoPuro) {
return argon2.hash(senhaEmTextoPuro, {
type: argon2.argon2id,
memoryCost: 19456, // 19 MiB
timeCost: 2,
parallelism: 1,
});
}
async function verificarSenha(hashArmazenado, senhaEmTextoPuro) {
return argon2.verify(hashArmazenado, senhaEmTextoPuro);
}O hash resultante já vem no formato auto-descritivo $argon2id$v=19$m=...,t=...,p=...$salt$hash, o que significa que o salt e os parâmetros usados ficam embutidos na própria string — não é preciso guardar isso em colunas separadas no banco.
Migrando de bcrypt ou PBKDF2 para Argon2
Você não consegue simplesmente “converter” hashes antigos para Argon2, porque o hash é uma via de mão única — não é possível reverter para o texto puro. O padrão de mercado é o rehash progressivo no login:
- O usuário faz login normalmente e a senha em texto puro chega ao servidor.
- Você verifica contra o hash antigo (bcrypt/PBKDF2), como sempre fez.
- Se a autenticação for bem-sucedida, você aproveita que já tem a senha em texto puro naquele momento e gera um novo hash com Argon2id, substituindo o antigo no banco.
Em poucos meses, a base de usuários ativos migra organicamente, sem precisar forçar reset de senha para ninguém.
Quando Argon2 NÃO é a escolha certa
Vale uma ressalva importante: se o seu ambiente exige conformidade FIPS 140-2/140-3 (comum em setor público federal americano, saúde e alguns setores financeiros), o Argon2 ainda não está na lista de primitivas aprovadas. Nesses casos, PBKDF2-SHA256 com pelo menos 600.000 iterações continua sendo a opção sancionada, mesmo sendo criptograficamente mais fraco contra GPUs do que o Argon2.
Resumo prático
- Use Argon2id para qualquer aplicação nova.
- Parâmetro mínimo recomendado pelo OWASP: m=19 MiB, t=2, p=1 — aumente se seu servidor tiver folga.
- Faça o benchmark no seu próprio hardware, não copie números de blog.
- Migre bases legadas via rehash no login, nunca convertendo hashes diretamente.
- Em ambientes com exigência FIPS, use PBKDF2-SHA256 com no mínimo 600 mil iterações.
Referências
- OWASP Password Storage Cheat Sheet — cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
- RFC 9106 (Argon2), IETF
Seja o primeiro a comentar