Argon2id vs Bcrypt vs Scrypt: Quebrar Custa 12,5x [2026]

Uma fuga de dados com palavras-passe em texto simples é um desastre imediato. Mas mesmo quando a base de dados está “hasheada”, o algoritmo escolhido decide se um atacante gasta 40 mil dólares ou 500 mil dólares em GPUs para as recuperar. Essa diferença de custo é o motivo pelo qual engenheiros de backend continuam a debater Argon2id, bcrypt e scrypt em 2026, muito depois de existirem alternativas mais recentes no papel. Este artigo compara os três algoritmos com parâmetros reais da OWASP, exemplos de frameworks que os usam em produção e um guia prático para migrar sem bloquear os utilizadores no próximo login.

A pergunta não é académica. Cada base de dados de autenticação comprometida acaba, mais cedo ou mais tarde, num fórum de venda de dados, e o algoritmo de hashing usado decide se essa fuga se transforma em milhões de contas quebradas em dias ou num incidente contido que dá tempo à equipa de segurança para forçar resets em massa. Escolher entre estes três algoritmos não é só uma questão de gosto técnico, é uma decisão que se paga (ou se poupa) no dia em que a base de dados é roubada.

O que é hashing de palavras-passe e porque continua a ser um problema em 2026

Hashing de palavras-passe transforma o texto que o utilizador escreve num valor irreversível guardado na base de dados. Quando alguém faz login, a aplicação recalcula o hash e compara-o com o valor guardado, sem nunca reconstruir a palavra-passe original. A cheat sheet oficial da OWASP é direta sobre o ponto de partida: funções rápidas como SHA-256 não servem para palavras-passe, porque permitem a um atacante testar milhões de combinações por segundo assim que rouba a base de dados.

É aqui que entram os algoritmos de hashing adaptativo: Argon2id, bcrypt, scrypt e PBKDF2. Todos partilham a mesma ideia, tornar o cálculo do hash deliberadamente lento e caro. A diferença está em como conseguem essa lentidão. Argon2id e scrypt exigem também memória RAM, o que encarece drasticamente o uso de placas gráficas para adivinhar palavras-passe em paralelo. O bcrypt, mais antigo, depende quase só de ciclos de CPU. Essa distinção técnica é o que separa uma fuga de dados “contida” de uma fuga que devolve milhões de palavras-passe em texto simples num fórum de hackers dentro de semanas.

Em 2026, o problema não desapareceu, apenas mudou de forma. Bases de código antigas continuam a usar MD5 ou SHA-1 sem salt, novas equipas escolhem bcrypt por hábito sem saber que existe uma opção melhor, e equipas que já usam Argon2id muitas vezes configuram-no com parâmetros fracos que anulam a vantagem teórica. Perceber as diferenças reais entre os três algoritmos, com números e não com opiniões, é o que evita repetir esses erros.

Argon2id, bcrypt e scrypt: as três opções que a OWASP recomenda

A própria OWASP resume a escolha em três frases: usar Argon2id sempre que possível, cair para scrypt quando Argon2id não está disponível e reservar o bcrypt para sistemas legados. Vale a pena perceber porque essa ordem existe.

Argon2id: o vencedor da competição, hoje o recomendado por defeito

O Argon2 venceu a Password Hashing Competition de 2015, um concurso aberto de vários anos organizado pela comunidade criptográfica para escolher o sucessor do bcrypt e do scrypt. Existem três variantes (Argon2d, Argon2i, Argon2id) e a OWASP recomenda especificamente a Argon2id, porque combina resistência a ataques por canal lateral com resistência a ataques baseados em GPU. O algoritmo aceita três parâmetros configuráveis: memória (m), iterações (t) e grau de paralelismo (p), o que dá controlo fino sobre o equilíbrio entre custo de CPU e custo de RAM. A especificação está formalizada na RFC 9106 do IETF, publicada em 2021 e ainda em vigor sem alterações em 2026.

scrypt: a alternativa memory-hard mais antiga

Criado por Colin Percival em 2009, o scrypt foi o primeiro algoritmo de hashing de palavras-passe amplamente adotado a exigir memória, não só tempo de CPU. Os seus três parâmetros, custo de memória (N), tamanho de bloco (r) e paralelismo (p), funcionam de forma parecida à do Argon2id, mas com menos flexibilidade e sem a resistência específica a ataques por canal lateral que a variante “id” do Argon2 oferece. A OWASP mantém o scrypt como segunda escolha oficial, útil sobretudo em ambientes onde a biblioteca Argon2 não está disponível, por exemplo em algumas linguagens mais antigas ou em hardware embutido com bibliotecas criptográficas limitadas.

bcrypt: o standard de facto, agora considerado legado

O bcrypt nasceu em 1999, derivado da cifra Blowfish, e durante quase duas décadas foi a resposta óbvia à pergunta “como guardo palavras-passe em segurança”. Continua largamente suportado, simples de implementar e testado à exaustão em produção. O problema é que não usa memória como fator de custo, apenas um “work factor” que controla o número de rondas de processamento. Isso torna-o vulnerável a paralelização massiva em GPUs e ASICs, algo que não existia à escala atual quando foi desenhado. Tem ainda uma limitação prática pouco conhecida: só processa os primeiros 72 bytes da palavra-passe, o resto é ignorado silenciosamente em muitas implementações.

Tabela comparativa: especificações técnicas lado a lado

Antes de comparar números de desempenho, ajuda ver as características estruturais dos três algoritmos numa única tabela.

Característica	Argon2id	bcrypt	scrypt
Ano de criação	2015	1999	2009
Origem	Vencedor da Password Hashing Competition	Derivado da cifra Blowfish	Criado por Colin Percival
Recomendação OWASP 2026	1ª escolha	3ª escolha (legado)	2ª escolha
Exige memória (memory-hard)	Sim	Não	Sim
Parâmetros configuráveis	Memória (m), iterações (t), paralelismo (p)	Work factor (cost)	Custo de memória (N), tamanho de bloco (r), paralelismo (p)
Resistência a canal lateral	Alta (variante “id” híbrida)	Não aplicável	Baixa/média
Limite de tamanho da entrada	Sem limite prático	72 bytes	Sem limite prático
Formalizado em RFC/standard	RFC 9106 (IETF, 2021)	Sem RFC formal	RFC 7914 (IETF, 2016)
Suporte em bibliotecas modernas	Amplo (Node.js, Python, Java, Rust, Go)	Universal	Amplo, menos comum que bcrypt
Configuração mínima recomendada (OWASP)	m=19456 (19 MiB), t=2, p=1	Work factor ≥ 10	N=2^17 (128 MiB), r=8, p=1
Custo típico por hash (config. recomendada)	~150-250 ms	~250 ms	~200-250 ms
Adoção como default em frameworks novos	Crescente, ainda minoritária	Dominante	Rara como default

O padrão que salta à vista é que o Argon2id ganha em quase todos os critérios técnicos, exceto na adoção real. Isso não é uma contradição, é inércia de engenharia: mudar o hasher de palavras-passe de uma aplicação em produção é uma operação delicada, e “se não está partido, não mexas” continua a ser a lógica dominante em muitas equipas.

Benchmarks de desempenho: tempo de hash, memória e CPU

A cheat sheet da OWASP publica cinco configurações equivalentes de Argon2id e cinco de scrypt, todas com o mesmo nível de defesa e apenas um trade-off diferente entre CPU e RAM. Isto é útil porque mostra que “usar Argon2id” não é uma decisão única, é escolher onde gastar o orçamento de hardware do servidor.

Algoritmo e configuração	Memória usada	Trade-off
Argon2id: m=47104, t=1, p=1	46 MiB	Mais RAM, menos iterações de CPU
Argon2id: m=19456, t=2, p=1	19 MiB	Configuração mínima recomendada
Argon2id: m=12288, t=3, p=1	12 MiB	Menos RAM, mais CPU
Argon2id: m=9216, t=4, p=1	9 MiB	Ainda menos RAM, mais iterações
Argon2id: m=7168, t=5, p=1	7 MiB	Mínimo de memória viável
scrypt: N=2^17, r=8, p=1	128 MiB	Máxima resistência a GPU nesta lista
scrypt: N=2^16, r=8, p=2	64 MiB	Metade da memória, mais paralelismo
scrypt: N=2^15, r=8, p=3	32 MiB	Configuração intermédia
scrypt: N=2^14, r=8, p=5	16 MiB	Baixo consumo de RAM
bcrypt: work factor ≥ 10	~4 KB	Sem controlo sobre memória, só CPU

Todas as configurações de Argon2id e scrypt nesta lista foram desenhadas pela OWASP para gastar aproximadamente o mesmo tempo de cálculo num servidor típico, algo entre 150 e 300 milissegundos. A diferença brutal está na memória: o bcrypt usa cerca de 4 KB, enquanto até a configuração mínima de Argon2id já usa 7 MiB, quase duas mil vezes mais. É essa memória que encarece o uso de GPUs, porque uma placa gráfica tem milhares de núcleos mas memória partilhada limitada, ao contrário de um CPU com muita RAM disponível por núcleo.

Análises técnicas publicadas em 2025 e 2026 sobre desempenho em servidores de autenticação apontam para números semelhantes quando testados em hardware comparável: bcrypt com work factor 12 e Argon2id com 64 MiB de memória rondam ambos os 200-250 ms por verificação, mas Argon2id consegue manter esse tempo mesmo sob ataques distribuídos, porque cada tentativa exige reservar a mesma quantidade de memória, o que limita o número de tentativas simultâneas possíveis por GPU.

Na prática, isto significa que um servidor de autenticação com Argon2id bem configurado processa um número de logins por segundo semelhante ao de um servidor com bcrypt, mas obriga o atacante a competir pela mesma memória que o próprio servidor usa para servir utilizadores legítimos. Um ataque de força bruta distribuído por várias GPUs em paralelo esbarra rapidamente no limite de memória disponível em cada placa, algo que não acontece com bcrypt, onde o gargalo é quase só o relógio do processador.

Quanto custa quebrar uma palavra-passe? A economia do ataque por GPU

A pergunta mais prática para quem decide qual algoritmo usar não é “qual é mais rápido a verificar um login”, é “quanto custaria a um atacante quebrar isto”. Estimativas de custo de aluguer de GPU divulgadas em análises técnicas de 2025-2026 sobre cracking de palavras-passe apontam para uma diferença de custo enorme entre algoritmos, ao tentar quebrar uma palavra-passe de 8 caracteres:

PBKDF2-SHA256 (600 mil iterações): cerca de 3 dias de GPU alugada, aproximadamente 5.000 dólares
bcrypt (work factor 12): cerca de 30 dias de GPU alugada, aproximadamente 40.000 dólares
Argon2id (128 MiB, t=3): cerca de 500 dias de GPU alugada, aproximadamente 500.000 dólares

Isto representa uma diferença de custo de aproximadamente 12,5 vezes entre bcrypt e Argon2id para a mesma classe de palavra-passe, e de cerca de 100 vezes entre PBKDF2 e Argon2id. Estes números são estimativas, não certezas absolutas, porque dependem do preço de mercado da hora de GPU no momento do ataque e do hardware específico usado. Mas a ordem de grandeza é o que importa: para um atacante que rouba uma base de dados com milhões de palavras-passe hasheadas, gastar 40 mil dólares para as quebrar em massa é um investimento com retorno óbvio. Gastar 500 mil dólares muda completamente o cálculo económico, sobretudo se as contas comprometidas não valerem esse montante em fraude.

Vale notar que estes valores assumem palavras-passe de complexidade média, nem trivialmente fracas nem extremamente longas. Uma palavra-passe curta e comum continua vulnerável a qualquer um dos três algoritmos, porque a lista de candidatos a testar é pequena. A escolha do algoritmo de hashing protege sobretudo contra ataques de força bruta em larga escala, não substitui a exigência de palavras-passe minimamente robustas por parte dos utilizadores.

O salt continua a ser o complemento indispensável a qualquer um destes algoritmos. Sem um salt único por utilizador, um atacante calcula o hash de uma palavra-passe comum uma única vez e compara-o contra a base de dados inteira, quebrando potencialmente milhares de contas em simultâneo através de tabelas pré-calculadas (rainbow tables). Com salt, cada conta exige um cálculo independente, o que multiplica o custo total do ataque pelo número de utilizadores visados. Todas as bibliotecas modernas de Argon2id, bcrypt e scrypt geram o salt automaticamente, mas implementações manuais antigas ainda falham nesse ponto básico.

Custo de infraestrutura: o preço da segurança em produção

Os três algoritmos são gratuitos e de código aberto, não há licenciamento a pagar. O custo real está no consumo de CPU e memória do servidor de autenticação, que se traduz em faturas de cloud maiores quanto mais forte for a configuração escolhida.

Item de custo	bcrypt	scrypt	Argon2id
Licenciamento	Grátis (open source)	Grátis (open source)	Grátis (open source)
Custo de CPU por verificação	Baixo a médio	Médio	Médio
Custo de RAM por verificação	Insignificante (~4 KB)	Alto (16-128 MiB por config.)	Alto (7-46 MiB por config.)
Custo extra estimado por milhão de autenticações vs. bcrypt	Base de comparação	Ligeiramente superior	Ordem de poucos cêntimos de dólar
Impacto em auto-scaling de servidores	Mínimo	Moderado, atenção a picos de login	Moderado, atenção a picos de login
Custo de aluguer de GPU para quebrar (8 carateres)	~$40.000	Entre bcrypt e Argon2id	~$500.000

O detalhe que costuma decidir a discussão dentro de uma equipa de engenharia é a linha do meio: o custo extra de infraestrutura para passar de bcrypt para Argon2id fica normalmente na casa dos cêntimos de dólar por milhão de autenticações, segundo estimativas de custo operacional publicadas em guias técnicos de 2025-2026 sobre hashing de palavras-passe em escala. Comparado com o salto de 40 mil para 500 mil dólares no custo de ataque, a decisão deixa de ser sobre desempenho e passa a ser puramente sobre inércia organizacional.

Isto muda em aplicações com volumes de login extremamente altos, como uma rede social com centenas de milhões de utilizadores ativos por dia, onde mesmo um aumento pequeno em milissegundos por login se multiplica em milhares de núcleos de CPU adicionais. Nesses casos, escolher uma configuração de Argon2id mais leve em memória (por exemplo m=9216, t=4) em vez da mais pesada (m=47104, t=1) permite manter a segurança sem disparar a fatura de cloud.

Equipas de plataforma que gerem clusters de autenticação partilhados por várias aplicações costumam resolver este equilíbrio isolando o serviço de hashing num microserviço próprio, com o seu próprio orçamento de CPU e memória, em vez de deixar o cálculo do hash competir com o resto da lógica de negócio no mesmo processo. Isso facilita ajustar os parâmetros de Argon2id de forma isolada, medir o impacto real no tempo de resposta e escalar apenas essa camada quando o volume de logins cresce, sem ter de replicar toda a aplicação.

O que dizem a OWASP, o NIST e a Password Hashing Competition

A recomendação mais citada do setor continua a ser a da própria OWASP, cuja cheat sheet de armazenamento de palavras-passe resume a hierarquia em três passos: usar Argon2id com memória mínima de 19 MiB, iteração mínima de 2 e paralelismo 1, cair para scrypt com N=2^17 se isso não estiver disponível, e reservar o bcrypt com work factor 10 ou mais para sistemas legados que não conseguem migrar. Para ambientes que exigem conformidade FIPS-140, a mesma cheat sheet recomenda PBKDF2 com pelo menos 600 mil iterações e HMAC-SHA-256 como função interna.

O NIST Special Publication 800-63B, a referência americana para gestão de identidade digital, segue uma linha semelhante: exige o uso de uma função de derivação de chave aprovada, salt único por utilizador e um fator de trabalho ajustado ao hardware disponível, sem impor um único algoritmo obrigatório. Já a Password Hashing Competition, organizada entre 2013 e 2015 por um painel internacional de criptógrafos, continua a ser a referência histórica que legitimou o Argon2 como sucessor natural do bcrypt e do scrypt, depois de avaliar dezenas de candidatos submetidos por equipas académicas e da indústria.

Nenhuma destas normas trata bcrypt ou scrypt como inseguros. Tratam-nos como aceitáveis com a configuração certa, mas ultrapassados pela opção mais recente quando a escolha está disponível. É uma diferença importante: migrar de bcrypt para Argon2id é uma melhoria recomendada, não uma correção de urgência.

Esta distinção entre “recomendado” e “obrigatório” é o que costuma gerar confusão dentro das equipas de segurança. Um auditor externo que assinale bcrypt como falha crítica numa avaliação de risco está, na maioria dos casos, a exagerar a gravidade, desde que o work factor esteja acima de 10 e o salt seja único por utilizador. O risco real concentra-se nos sistemas que ainda usam MD5, SHA-1 sem salt, ou pior, texto simples, não nos que usam bcrypt bem configurado. Vale a pena reservar essa urgência para os casos que a merecem.

Casos de uso reais: quem usa cada algoritmo em produção

A teoria é uma coisa, a prática das frameworks mais usadas do mundo é outra. Olhar para o que os projetos open source escolhem por defeito ajuda a perceber porque o bcrypt continua tão presente apesar de já não ser a recomendação número um.

Django (Python): usa PBKDF2 com HMAC-SHA256 por defeito nas versões 5.x e 6.x, com contagens de iterações que a equipa do projeto aumenta em cada versão. Argon2id, bcrypt e scrypt estão disponíveis na lista de hashers suportados, mas exigem ativação manual.
Ruby on Rails: o método has_secure_password usa bcrypt por defeito desde sempre. A partir de 2025, a framework passou a suportar Argon2 como alternativa opcional, ativável ao instalar a gem argon2 e indicar algorithm: :argon2.
WordPress: mudou o seu esquema de hashing na versão 6.8, lançada em abril de 2025, substituindo o antigo phpass por bcrypt nativo via password_hash() do PHP, com um pré-hash SHA-384.
Spring Security (Java): usa um DelegatingPasswordEncoder que, por defeito, aplica BCryptPasswordEncoder com força 10, embora recomende explicitamente o BCryptPasswordEncoder como implementação preferida na documentação atual.
Laravel (PHP): tal como o Rails, usa bcrypt como driver de hashing por defeito, com argon e argon2id disponíveis como alternativas configuráveis quando a extensão libsodium ou libargon2 está presente.
ASP.NET Core Identity: usa PBKDF2 com HMAC-SHA256, salt de 128 bits e, nas versões mais recentes, 100 mil iterações por defeito (subida face às 10 mil iterações de versões anteriores).
Ecossistema Node.js: os pacotes bcrypt e bcryptjs continuam a dominar os downloads semanais no npm, na casa dos milhões, enquanto os pacotes de Argon2 como argon2 e @node-rs/argon2 ficam bem abaixo, na casa das centenas de milhares.

O padrão é consistente: nenhuma das grandes frameworks mudou o seu default para Argon2id em 2025 ou 2026. Todas continuam a apostar em bcrypt (Rails, WordPress, Laravel, Spring) ou em variantes de PBKDF2 (Django, ASP.NET Core). Isto não invalida a recomendação da OWASP, mostra apenas que mudar um default usado por milhões de aplicações é uma decisão lenta, cheia de considerações sobre compatibilidade retroativa que pesam mais do que o ganho teórico de segurança.

Há uma lógica clara por trás dessa cautela. O WordPress só mexeu no seu esquema de hashing em 2025, depois de mais de uma década com phpass, precisamente porque qualquer mudança nesse ponto arrisca quebrar milhões de sites geridos por administradores sem conhecimento técnico avançado. O mesmo raciocínio aplica-se ao Rails e ao Laravel: acrescentar suporte a Argon2 como opção é barato e sem risco, mas trocar o default de bcrypt para Argon2id obrigaria a testar exaustivamente a compatibilidade com milhares de gemas e pacotes de terceiros que assumem bcrypt como formato de hash.

A própria OWASP descreve a técnica padrão para atualizar o fator de trabalho ou trocar de algoritmo sem forçar um reset de palavra-passe em massa: fazer o rehash de forma incremental, no momento em que o utilizador faz login com sucesso. Nesse instante a aplicação já tem a palavra-passe em texto simples disponível em memória (antes de a descartar), o que é a única oportunidade segura para recalcular o hash com o novo algoritmo.

O fluxo típico segue estes passos:

Adicionar uma coluna ou campo que identifique o algoritmo e a versão do hash guardado (por exemplo, um prefixo como $argon2id$ já inclui essa informação nativamente).
Manter a lógica de verificação antiga (bcrypt/scrypt) a funcionar em paralelo com a nova (Argon2id).
No momento do login, verificar primeiro com o algoritmo indicado no hash guardado.
Se a verificação for bem-sucedida, recalcular o hash imediatamente com Argon2id e os novos parâmetros, substituindo o valor antigo na base de dados.
Utilizadores que não fizerem login durante meses ou anos ficam com o hash antigo até lá, por isso convém decidir se, ao fim de um prazo definido, se força um reset de palavra-passe para esses casos.

Em código, a lógica de verificação e rehash costuma ficar assim numa aplicação Node.js:

const bcrypt = require('bcrypt');
const argon2 = require('argon2');

async function verificarEAtualizar(hashGuardado, passwordTexto) {
  if (hashGuardado.startsWith('$2')) {
    // hash antigo em bcrypt
    const valido = await bcrypt.compare(passwordTexto, hashGuardado);
    if (!valido) return { valido: false };

    // login correto: gerar novo hash em Argon2id
    const novoHash = await argon2.hash(passwordTexto, {
      type: argon2.argon2id,
      memoryCost: 19456, // 19 MiB, mínimo recomendado pela OWASP
      timeCost: 2,
      parallelism: 1,
    });
    return { valido: true, novoHash };
  }

  // já está em Argon2id
  const valido = await argon2.verify(hashGuardado, passwordTexto);
  return { valido };
}

Este padrão evita a alternativa mais drástica, forçar todos os utilizadores a redefinir a palavra-passe de imediato, que costuma gerar picos de pedidos de suporte e queda temporária na taxa de login bem-sucedido. A migração incremental é mais lenta, mas silenciosa do ponto de vista do utilizador final.

Antes de ativar isto em produção, vale a pena testar a nova configuração num ambiente de staging com uma cópia da base de dados, medindo o tempo médio de resposta do endpoint de login sob carga realista. Se o tempo de hash disparar acima de um segundo com o tráfego habitual, é preferível reduzir os parâmetros de memória ou iterações antes do lançamento do que descobrir o problema já com utilizadores reais a queixarem-se de logins lentos. Manter as duas rotinas de verificação ativas durante algumas semanas, com métricas a acompanhar a percentagem de contas já migradas, também ajuda a decidir quando é seguro remover o código legado do bcrypt ou do scrypt.

Erros comuns de configuração que anulam a segurança

Trocar de algoritmo não serve de nada se a configuração for mal feita. Os erros mais frequentes observados em auditorias de código incluem usar Argon2id com os parâmetros de exemplo de um tutorial online, muitas vezes bem abaixo do mínimo recomendado pela OWASP, o que anula a vantagem de memória do algoritmo. Outro erro comum é reutilizar o mesmo salt para todos os utilizadores, ou pior, não usar salt nenhum, algo que nenhum dos três algoritmos permite por defeito nas bibliotecas modernas, mas que ainda aparece em implementações manuais antigas.

Com bcrypt, o erro mais reportado é ignorar o limite de 72 bytes, o que faz com que palavras-passe longas sejam truncadas silenciosamente, criando colisões inesperadas entre palavras-passe diferentes que partilham os primeiros 72 caracteres. A própria OWASP alerta ainda contra a técnica de “pré-hash” com bcrypt (aplicar SHA-2 ou BLAKE3 antes de passar o valor ao bcrypt) sem cuidado, porque pode introduzir uma vulnerabilidade conhecida como password shucking, em que quebrar o hash interno equivale a quebrar a palavra-passe inteira.

Por fim, um erro de gestão mais do que técnico: escolher um work factor ou parâmetros de memória demasiado altos sem testar o impacto em produção. Se o cálculo do hash demorar mais de um segundo em picos de tráfego, um atacante pode explorar isso para lançar um ataque de negação de serviço simplesmente enviando muitos pedidos de login em simultâneo, esgotando a CPU do servidor de autenticação.

Também vale monitorizar o tempo real de hashing em produção, não apenas no momento em que a configuração é definida. Uma migração para uma instância de servidor mais lenta, uma alteração no plano de cloud ou um pico de utilizadores concorrentes pode fazer com que os mesmos parâmetros que eram seguros e rápidos há um ano passem a demorar o dobro do tempo hoje. Registar essa métrica num painel de observabilidade evita que a equipa descubra o problema só quando os utilizadores começam a reportar lentidão no login.

Prós e contras de cada algoritmo

Resumindo os pontos fortes e fracos de cada opção depois de todos os números acima:

Argon2id, prós: recomendação número um da OWASP, resistente a GPU e a canal lateral, parâmetros flexíveis, custo de infraestrutura marginal face ao ganho de segurança.
Argon2id, contras: ainda minoritário como default nas frameworks mais populares, exige mais RAM por verificação, requer ativação manual na maioria dos projetos.
bcrypt, prós: suporte universal em praticamente todas as linguagens, testado à exaustão em produção há mais de duas décadas, simples de implementar corretamente.
bcrypt, contras: não usa memória como fator de custo, vulnerável a paralelização em GPU, limite rígido de 72 bytes na entrada.
scrypt, prós: memory-hard como o Argon2id, boa segunda escolha quando Argon2id não está disponível, formalizado na RFC 7914.
scrypt, contras: menos flexível que Argon2id, sem a resistência específica a canal lateral, suporte em bibliotecas menos consistente entre linguagens.

Quando usar cada algoritmo: recomendações por caso de uso

Nem toda a aplicação tem as mesmas restrições, e a escolha certa depende do contexto de cada equipa:

Aplicação nova, sem base de utilizadores legada: usar Argon2id desde o primeiro dia, com a configuração mínima recomendada pela OWASP (m=19456, t=2, p=1), sem motivo para escolher outra coisa.
Sistema legado com bcrypt já em produção há anos: não é urgente migrar, mas vale a pena implementar o rehash incremental descrito acima e aumentar gradualmente o work factor do bcrypt como medida intermédia.
Ambiente regulado que exige certificação FIPS-140: usar PBKDF2 com HMAC-SHA-256 e pelo menos 600 mil iterações, porque é a única das opções aqui com implementações validadas para esse standard.
Hardware embutido ou linguagens com bibliotecas criptográficas limitadas: scrypt costuma ter melhor suporte do que Argon2 em ambientes mais restritos, o que o torna a segunda escolha prática, não só teórica.
Aplicação com volume de login extremamente alto (milhões de autenticações por hora): optar por uma configuração de Argon2id mais leve em memória, como m=9216, t=4, p=1, que mantém o nível de defesa recomendado sem disparar o custo de CPU e RAM à escala.
Migração de MD5 ou SHA-1 sem salt: tratar como prioridade máxima e imediata, independentemente do algoritmo de destino escolhido, porque essas funções nunca foram desenhadas para palavras-passe e são triviais de quebrar em massa.

Veredito final: qual escolher em 2026

Os números não deixam muita margem para dúvida técnica: Argon2id vence em resistência a GPU, em flexibilidade de configuração e em recomendação oficial da OWASP, do NIST e da comunidade criptográfica que organizou a Password Hashing Competition. A diferença de custo de ataque, cerca de 12,5 vezes mais caro quebrar Argon2id do que bcrypt para a mesma classe de palavra-passe, compensa largamente o aumento marginal no custo de infraestrutura, medido em cêntimos por milhão de autenticações.

Isto não torna o bcrypt uma escolha errada. Continua a ser seguro quando bem configurado, com work factor 10 ou mais, e a sua omnipresença em frameworks como Rails, Laravel e Spring Security significa que milhões de aplicações em produção não estão em risco imediato só por não terem migrado ainda. O scrypt fica no meio do caminho: uma opção sólida quando Argon2id não está disponível, mas sem motivo para ser a escolha inicial de um projeto novo.

Para uma equipa a começar um projeto hoje, a resposta é direta: Argon2id, com os parâmetros mínimos da OWASP como ponto de partida. Para uma equipa com bcrypt já em produção, a resposta é quase tão direta: não há pressa para migrar já, mas vale a pena planear a transição incremental descrita neste artigo antes que a próxima fuga de dados torne a decisão urgente em vez de estratégica.

O resumo em uma frase: bcrypt continua a ser uma escolha defensável, scrypt é uma alternativa sólida sem grande motivo para o preferir quando há outra opção, e Argon2id é onde qualquer equipa nova deveria começar. Os números de custo de ataque, entre 40 mil e 500 mil dólares para quebrar a mesma palavra-passe, tornam essa hierarquia mais do que uma preferência académica.

Perguntas frequentes

Argon2id é sempre melhor do que bcrypt?

Tecnicamente sim, segundo a recomendação da OWASP e a resistência superior a ataques por GPU. Na prática, um bcrypt bem configurado com work factor alto continua a proteger razoavelmente uma aplicação, apenas não é a opção mais forte disponível hoje.

Vale a pena migrar uma aplicação em produção de bcrypt para Argon2id?

Sim, mas sem urgência de emergência. A forma recomendada é o rehash incremental no momento do login, sem forçar reset de palavra-passe em massa nem interromper o serviço.

Porque é que o bcrypt só aceita 72 bytes de palavra-passe?

É uma limitação da cifra Blowfish em que o bcrypt se baseia, presente desde a sua criação em 1999. Palavras-passe mais longas são truncadas silenciosamente na maioria das implementações, por isso convém impor esse limite explicitamente na aplicação.

O scrypt ainda faz sentido em 2026?

Sim, como segunda escolha oficial da OWASP quando o Argon2id não está disponível na linguagem ou ambiente usado. Não há motivo para o escolher em vez de Argon2id quando ambos estão disponíveis.

Quanto custa realmente a um atacante quebrar uma palavra-passe hasheada com Argon2id?

Para uma palavra-passe de 8 caracteres com complexidade média, estimativas de custo de aluguer de GPU publicadas em análises técnicas de 2025-2026 apontam para cerca de 500.000 dólares, contra aproximadamente 40.000 dólares para a mesma palavra-passe protegida com bcrypt.

PBKDF2 ainda é uma opção válida?

Sim, sobretudo em ambientes que exigem certificação FIPS-140, onde a OWASP recomenda PBKDF2 com HMAC-SHA-256 e pelo menos 600 mil iterações como alternativa validada. Fora desse contexto regulado, Argon2id ou scrypt continuam preferíveis.

Que erro de configuração anula mais rapidamente a segurança do Argon2id?

Usar parâmetros de memória e iterações copiados de um exemplo genérico, muitas vezes bem abaixo do mínimo de 19 MiB e 2 iterações recomendado pela OWASP. Isso reduz o algoritmo a uma versão pouco mais forte do que um hash rápido comum.

Preciso de mudar de algoritmo se ainda uso MD5 ou SHA-1 para palavras-passe?

Sim, com prioridade máxima. Nenhum dos três algoritmos comparados neste artigo é o problema nesse cenário, o problema é usar uma função de hash rápida, desenhada para verificação de integridade e não para proteção de palavras-passe, o que a torna trivial de quebrar em massa.