Gerador e verificador de hash de palavras-passe

Crie e verifique hashes de palavras-passe com bcrypt, scrypt, Argon2id e PBKDF2 inteiramente no seu navegador — gere cadeias em formato PHC, verifique uma palavra-passe candidata contra um hash existente e inspecione os parâmetros escondidos dentro dele. Nada é enviado.
Apenas para palavras-passe de teste. As palavras-passe reais dos utilizadores nunca devem ser coladas em nenhuma página web. Esta ferramenta corre inteiramente no seu navegador — as cadeias nunca saem do seu separador — mas uma fuga de dados começa com uma única colagem.
custo bcrypt (2^custo rondas)
variante bcrypt a variante só altera o prefixo; o próprio hash é idêntico
N do scrypt (custo de CPU)
r / p do scrypt r =  p = tamanho do bloco 128·r bytes; memória = 128·N·r bytes (N=214, r=8 → 16 MiB)
Argon2id m (memória)
Argon2id t / p t =  p = t = passagens; p = paralelismo (faixas)
PRF do PBKDF2
Iterações PBKDF2  OWASP 2023: 600.000 para HMAC-SHA-256 (1.300.000 para SHA-1, 210.000 para SHA-384/512)
Comprimento da saída (bytes)  A saída do bcrypt tem tamanho fixo de 23 bytes (31 caracteres em base64 do bcrypt)
AlgoritmoParâmetrosMemóriaComprimento da saídaTempo (neste navegador)
bcryptcusto 124 KiB23 bytes-
scryptN=214, r=8, p=116 MiB32 bytes-
Argon2idm=19 MiB, t=2, p=119 MiB32 bytes-
PBKDF2HMAC-SHA-256, 600.000 iterações~032 bytes-
Folha de cheat de parâmetros (Folha de Cheat de Armazenamento de Palavras-passe do OWASP, mínimos de 2023)
AlgoritmoMínimoNotas
Argon2idm = 19 MiB (19.456 KiB), t = 2, p = 1preferido; voraz em memória
scryptN = 214, r = 8, p = 1voraz em memória (16 MiB no mínimo)
bcryptcusto = 10só fator de trabalho; limite de palavra-passe de 72 bytes
PBKDF2-HMAC-SHA256600.000 iteraçõesdureza só por iteração — amiga das GPUs, última escolha
As predefinições desta página estão em ou acima de todos os mínimos. Para produção escolha primeiro o Argon2id, depois o scrypt ou o bcrypt se o primeiro não estiver disponível; o PBKDF2 só por razões de conformidade FIPS.
Interoperabilidade com PHP — password_hash($pw, PASSWORD_BCRYPT) emite $2y$10$...: cole-a em Verificar com a palavra-passe candidata e esta página responde exatamente o que password_verify() responderia. A saída de PASSWORD_ARGON2ID ($argon2id$v=19$m=65536,t=4,p=1$...) também verifica. As cadeias PHC do passlib, do django-argon2 e de encapsulamento crypto.scrypt também são analisadas.
Autoteste
Volta a executar o motor da página contra vetores públicos: a suíte de testes crypt_blowfish para bcrypt, cadeias scrypt e Argon2id geradas pelo node/OpenSSL, os vetores PBKDF2 da RFC 6070 e o conjunto público de SHA-256, mais ciclos de gerar-e-verificar em todos os algoritmos e testes negativos (uma palavra-passe errada tem de falhar, cadeias mal formadas têm de ser rejeitadas). Nada é enviado para lado nenhum.
Hash de palavras-passe explicado do zero
Em resumo: um hash de palavra-passe é deliberadamente lento (e de preferência voraz em memória), para que roubar a base de dados não permita a um atacante tentar milhares de milhões de adivinhações por segundo — o oposto do objetivo de um hash rápido como o SHA-256, feito para velocidade.
Porque não basta aplicar SHA-256 à palavra-passe?

O SHA-256 numa GPU moderna corre a milhares de milhões de adivinhações por segundo. Uma palavra-passe de 8 caracteres tem bem menos de 1013 combinações — horas de tempo de GPU, minutos num equipamento grande. As funções de hash de palavras-passe (KDFs) combatem isto com parâmetros de custo: o bcrypt repete o seu núcleo 2custo vezes, o PBKDF2 itera HMAC centenas de milhares de vezes, e o scrypt e o Argon2id exigem ainda megabytes de memória por adivinhação, para que as GPUs (rápidas mas pobres em memória por núcleo) percam a vantagem. Um sal — aleatório, guardado às claras dentro da cadeia de hash — trava as tabelas arco-íris pré-calculadas e obriga cada adivinhação a ser calculada de novo para cada utilizador.

Os quatro algoritmos nesta página
AlgoritmoAnoDurezaFormatoCuidado com
bcrypt1999CPU (2custo configurações de chave)$2b$12$ + sal de 22 caracteres + hash de 31 caractereslimite de palavra-passe de 72 bytes (tudo o que exceder 72 é silenciosamente ignorado); o byte NUL termina a palavra-passe na implementação C original
PBKDF22000 (RFC 2898/8018)CPU (iterações)$pbkdf2-sha256$i=600000$ + sal + hash (estilo passlib)sem custo de memória — as GPUs e os ASICs adoram; só o número de iterações é ajustável
scrypt2009 (RFC 7914)CPU + memória (128·N·r bytes)$scrypt$ln=14,r=8,p=1$ + sal + hashN tem de ser uma potência de dois; a memória cresce linearmente com r
Argon2id2015 (vencedor do PHC, RFC 9106)CPU + memória (m KiB, t passagens)$argon2id$v=19$m=19456,t=2,p=1$ + sal + hashArgon2i (independente dos dados) vs Argon2d (dependente dos dados) vs Argon2id (híbrido) — escolha sempre id, a não ser que saiba porque não
Dureza de memória vs dureza de cálculo

Uma GPU tem milhares de núcleos, mas cada núcleo tem acesso a pouca memória rápida. Uma KDF que precisa de 19 MiB de conjunto de trabalho por adivinhação limita um atacante a tantas adivinhações paralelas quantos blocos de 19 MiB de memória tiver — por isso o Argon2id com 19 MiB pode ser, na prática, mais forte do que o bcrypt com custo 15, apesar de demorar menos tempo no seu portátil. O PBKDF2 não tem resposta para isto: o seu único botão é o número de iterações, e o silício escala-o linearmente.

Ler uma cadeia PHC

O formato modular-crypt / PHC é autodescritivo: em $argon2id$v=19$m=19456,t=2,p=1$ICEiIyQlJicoKSorLC0uLw$WTGpK4hf... os campos são o algoritmo, a versão, os parâmetros (m = memória em KiB, t = passagens, p = faixas), o sal em base64 e o hash em base64. O bcrypt é anterior à norma e usa a sua forma compacta própria: variante $2b$, depois 12 de custo, e depois o sal e o hash no alfabeto base64 próprio do bcrypt (./A-Za-z0-9). A verificação desta página aceita todos estes formatos e mostra os campos analisados — cole qualquer hash que encontre e veja em que se decompõe.

Erros comuns
  • Hash rápido para palavras-passe. As colunas de palavras-passe em MD5/SHA-1/SHA-256 caem perante GPUs comuns a milhares de milhões de adivinhações por segundo. Use o Gerador de Hash para ficheiros e dados; use os algoritmos desta página para palavras-passe.
  • Partilhar um sal. Um só sal para todos os utilizadores significa que palavras-passe iguais têm hashes iguais e as tabelas arco-íris voltam a funcionar. Cada hash aqui recebe um sal aleatório novo de 16 bytes.
  • Ignorar os 72 bytes do bcrypt. "a"*100 e "a"*72 produzem o mesmo hash — a cauda é descartada. Esta página avisa na caixa de entrada quando a palavra-passe excede 72 bytes. O Argon2 não tem esse limite.
  • Comparar hashes com == no seu próprio código. A verificação tem de ser de tempo constante; o motor da página faz isso internamente (recalcula e compara os bytes guardados), mas se copiar a abordagem, use uma comparação de tempo constante.
  • Ajustar parâmetros numa máquina de desenvolvimento rápida. Vise cerca de 250–500 ms de cálculo no hardware mediano dos seus utilizadores de produção, não na sua estação de trabalho. O botão Testar mostra o que este navegador de facto experimenta.
  • Recalcular o hash em cada verificação de login. Verifique primeiro; só volte a calcular o hash (p. ex. para aumentar o custo) depois de uma verificação bem-sucedida, e guarde a nova cadeia. A função PHP password_needs_rehash() existe precisamente para isto.
FAQ

Qual deve escolher? Argon2id com pelo menos os mínimos OWASP. Se o ambiente de execução não o oferecer: scrypt, depois bcrypt (com custo tal que o cálculo demore ≥250 ms). O PBKDF2 só quando a certificação o exigir.

Porque é que um sal aleatório aparece na cadeia de saída? O sal não é um segredo — é guardado às claras dentro da cadeia PHC de propósito, por isso a verificação precisa apenas da cadeia e da palavra-passe candidata. A sua função é a unicidade, não o segredo.

A variante importa ($2a$ / $2b$ / $2y$)? Para palavras-passe ASCII produzem hashes idênticos; $2a$ é o original dos anos 90, $2b$ corrigiu um erro raro de extensão de sinal (2014), $2y$ é a marca do PHP de que a correção está presente. A verificação aceita as três.

Quanto tempo deve demorar um hash? Cerca de 250–500 ms por login em hardware de servidor. Abaixo de 100 ms e a quebra offline é barata; acima de 1 s os utilizadores queixam-se antes de a segurança melhorar.

Posso verificar um hash produzido noutro lado? Sim — cole-o e indique a palavra-passe candidata. Formatos conhecidos: password_hash do PHP (bcrypt $2y$ e Argon2id), passlib do Python, o hasher argon2 do django e o formato de cadeia scrypt usado pela ferramenta scrypt do Tarsnap.

O que faz o botão "testar"? Calcula a palavra-passe atual uma vez com cada algoritmo, com os parâmetros predefinidos da página, e reporta o tempo de relógio neste navegador — uma ideia das diferenças de custo, não uma medição rigorosa.