Pular para o conteúdo

Verificador de bcrypt e argon2

bcrypt & argon2 Checker

Gera o hash de uma senha com bcrypt num custo escolhido e confere uma senha contra um hash bcrypt existente. Detecta argon2, mas não o calcula.

Faz o hash de uma senha com bcrypt, ou confere uma senha contra um hash `$2a$`/`$2b$`/`$2y$` existente. A implementação é o `$2b$` do OpenBSD verificado contra os vetores publicados do crypt_blowfish da Openwall, e ela roda em um worker nesta aba.

🔒 Roda inteiramente no seu navegadorbcryptargon2passwordhash
Modo

Processado só nesta aba; nada é transmitido.

Custo

1.024 rodadas — o padrão de sempre.

Isto é o bcrypt como o OpenBSD define $2b$, conferido contra os vetores de teste publicados do Openwall crypt_blowfish e rodando inteiramente nesta aba. Só os primeiros 72 bytes de uma senha contam — o bcrypt é assim, não é um defeito daqui. Hashes $2x$ (feitos por um defeito do crypt_blowfish anterior a 2011) são recusados, e argon2 não está implementado.

Como usar

  1. Escolha hash ou verificar

    Fazer o hash precisa de um custo; verificar lê o custo do hash que você colar, porque ele fica guardado na string.

  2. Escolha um custo que você possa pagar

    Cada passo dobra o trabalho. 10 foi o padrão por anos, 12 é uma escolha sólida hoje, e 14 leva alguns segundos visíveis em um navegador — e esse é o ponto: leva o mesmo tempo para um atacante.

  3. Leia o veredicto

    Bate ou não bate. Tudo acontece na aba, então um hash de produção colado aqui não viaja a lugar nenhum.

Perguntas frequentes

Por que argon2 é recusado em vez de suportado?

Porque um argon2 confiável em um navegador significa distribuir um build de WebAssembly que este projeto não consegue auditar linha por linha. O bcrypt está implementado aqui em código que você pode ler, conferido contra vetores publicados. Recusar um hash argon2 é mais honesto do que uma resposta de aparência plausível saída de uma caixa-preta.

Por que minha senha longa verifica contra o hash errado?

O bcrypt só lê os primeiros 72 bytes. Duas senhas que compartilham seus primeiros 72 bytes são a mesma senha para ele: isso é o bcrypt em si, não esta implementação. Importa para uma frase secreta, e é uma das razões de as pessoas migrarem para argon2.

Por que fazer o hash da mesma senha duas vezes dá strings diferentes?

Porque cada execução gera um salt novo de 16 bytes, e o salt viaja dentro do hash. As duas strings verificam a mesma senha. Um hash de senha que é igual toda vez é um hash de senha sem salt, que é exatamente para o que as rainbow tables foram construídas.

$2a$, $2b$ e $2y$ são diferentes?

Não para nenhuma senha de 72 bytes ou menos, que são todas. Os prefixos registram antes ou depois de qual bug histórico um hash foi feito. `$2x$` é a exceção: marca hashes feitos por um bug do crypt_blowfish anterior a 2011, e esses são recusados aqui.

Pode receber de

Em seguida

Estas aceitam o que esta ferramenta produz, então o resultado pode ir direto.