Gerador Bcrypt

Gerador Bcrypt Online — Grátis, 100% Client-Side, Sem Cadastro

Gere e verifique hashes bcrypt inteiramente no seu browser — zero servidor, nenhum dado enviado. Todo processamento acontece localmente com bcryptjs, uma implementação pura em JavaScript. Abra o DevTools, observe a aba Network completamente vazia e confirme: sua senha nunca sai da máquina.

Esta ferramenta vai além do básico. Meça o tempo real de hashing no seu hardware para cada cost factor, decodifique qualquer hash bcrypt existente para entender sua estrutura, e copie código pronto para oito linguagens — tudo em um único lugar.

Como Usar o Gerador Bcrypt

Gerar um hash bcrypt a partir de uma senha leva menos de cinco segundos:

1. Cole ou digite sua senha no campo "Input Password" — o badge "CLIENT-SIDE SECURE" confirma que nenhuma requisição de rede será feita.
2. Ajuste o cost factor com o slider (4–18). Cost 12 é o padrão recomendado pelo OWASP; valores maiores aumentam a segurança mas também o tempo de hash.
3. Clique em "Generate Bcrypt Hash" — o hash aparece imediatamente, junto com o tempo exato que levou no seu dispositivo atual.
4. Copie o hash com o botão de cópia ou pressione Shift+Enter fora dos campos de input.

Para verificar uma senha contra um hash existente, mude para a aba Verify Hash, insira os dois valores e clique em "Verify Match" — você verá um checkmark verde ou X vermelho em milissegundos.

Exemplos de Hash Bcrypt

O bcrypt sempre produz uma string de exatamente 60 caracteres. Por causa do salt aleatório, a mesma senha hasheada duas vezes sempre produzirá hashes diferentes — mas ambos verificarão corretamente contra a senha original.

Exemplo — cost factor 12 (padrão OWASP):

Input:  minhasenhasecreta
Output: $2b$12$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa

Exemplo — mesma senha, hashes diferentes (salt aleatório):

Input:  minhasenhasecreta (hasheada duas vezes com cost 12)
Hash 1: $2b$12$nOUIs5kJ7naTuTFkBy1veu...
Hash 2: $2b$12$aBcDeFgHiJkLmNoPqRsTuv...  ← salt diferente, ambos válidos

Caso extremo — limite de 72 bytes:

Input 1: [72 caracteres 'a']
Input 2: [100 caracteres 'a']
Resultado: ambos produzem hashes equivalentes — bytes além de 72 são ignorados silenciosamente

O Formato do Hash Bcrypt — O Que Cada Parte Significa

Todo hash bcrypt tem exatamente a mesma estrutura. Para $2b$12$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa:

Os prefixos de versão: $2a$ é a spec original com um bug em implementações com caracteres de 8 bits; $2b$ é o padrão corrigido atual; $2y$ é o equivalente PHP de $2b$. Sempre use $2b$ em código novo.

O Que É Bcrypt e Por Que Importa?

Bcrypt é uma função de hash de senhas criada por Niels Provos e David Mazières em 1999, baseada na cifra Blowfish. Ao contrário do MD5 ou SHA-256 — que são funções rápidas de propósito geral — o bcrypt é intencionalmente lento. Seu cost factor é ajustável, permitindo aumentar o trabalho computacional à medida que o hardware evolui, mantendo ataques de força bruta economicamente inviáveis ao longo do tempo.

O bcrypt gera e embute automaticamente um salt aleatório único em cada hash. Isso previne ataques de rainbow table, onde atacantes usam tabelas pré-computadas para reverter hashes comuns. Mesmo que dois usuários tenham a mesma senha, seus hashes bcrypt serão diferentes.

Casos de Uso Comuns

• Sistemas de autenticação: Hash de senhas antes de armazenar no banco. No login, bcrypt.compare() roda o mesmo algoritmo com o salt armazenado e confirma o match em tempo constante, prevenindo timing attacks.
• Migração de algoritmos fracos: Re-hasheie progressivamente senhas de MD5/SHA-1 para bcrypt. No login bem-sucedido com o hash antigo, verifique a senha e substitua imediatamente o hash armazenado por um bcrypt.
• Calibração do cost factor: Execute o benchmark local no hardware do seu servidor de produção para encontrar o cost factor mais alto que mantenha a latência de login abaixo do seu threshold de UX (tipicamente 300ms–1s).
• Auditorias de segurança: Cole um hash existente no parser para verificar se usa $2b$, confirmar se o cost factor atende aos mínimos do OWASP, e checar se os comprimentos de salt e hash estão corretos.

Erros Comuns com Bcrypt

• Usar cost 4–8 em produção: Esses valores completam em menos de 1ms e não oferecem resistência significativa a força bruta. Cost 4 existe apenas para testes unitários onde velocidade importa. Use cost 10 como mínimo absoluto, cost 12 como padrão.
• Hashear hashes já hasheados: Rodar bcrypt em um hash bcrypt produz uma string duplamente codificada que nunca poderá ser verificada. Sempre faça hash apenas do texto original em claro.
• Ignorar o limite de 72 bytes: O bcrypt trunca silenciosamente a entrada em 72 bytes. Se sua aplicação permite senhas maiores que ~72 caracteres ASCII, considere pré-hashear com SHA-256 antes do bcrypt, ou use Argon2id que não tem esse limite.
• Armazenar o salt separadamente: O bcrypt embute o salt dentro da string de 60 caracteres. Você não precisa de coluna salt separada. Armazene apenas o hash bcrypt completo — a biblioteca extrai o salt automaticamente na verificação.

Perguntas Frequentes

Qual fator de custo (rounds) devo usar no bcrypt?

OWASP recomenda cost factor 12 como ponto de partida, visando aproximadamente 250ms por hash em hardware moderno. O valor correto depende do seu servidor específico — use o benchmark local desta página para medir o tempo real, depois escolha o fator mais alto que mantenha a latência de autenticação abaixo do seu threshold de UX (tipicamente 300ms–1s). Aumente o cost factor à medida que o hardware melhora.

Um hash bcrypt pode ser revertido ou decifrado?

Não. Bcrypt é uma função unidirecional — não existe método matemático para derivar a senha original de um hash. A única abordagem é força bruta: adivinhar senhas, hashear cada uma com o salt armazenado e comparar. O alto número de iterações torna isso computacionalmente caro. Um hash de cost 12 leva ~250ms por tentativa; adivinhar um bilhão de senhas levaria mais de 8.000 anos em uma única máquina.

Qual a diferença entre $2a$ e $2b$ no bcrypt?

$2a$ é a spec original de 1999. Algumas implementações tinham um bug em caso extremo ao hashear senhas com caracteres acima de 127 bytes. $2b$ corrige esse bug e é o padrão atual. $2y$ é uma variante PHP matematicamente equivalente ao $2b$. Para qualquer nova implementação, use $2b$. Hashes $2a$ existentes continuam funcionando na maioria dos casos — migração só é necessária se houver evidência do bug afetando seus usuários.

Bcrypt suporta senhas com mais de 72 caracteres?

O bcrypt processa apenas os primeiros 72 bytes de qualquer entrada. Caracteres além de 72 bytes são ignorados silenciosamente, então "a" × 72 e "a" × 100 produzem valores equivalentes e são mutuamente verificáveis. Se usuários podem criar senhas maiores que ~70 caracteres, considere pré-hashear com SHA-256 antes do bcrypt, ou mude para Argon2id que não tem limite de comprimento.

Devo usar bcrypt ou Argon2id em um projeto novo?

OWASP agora recomenda Argon2id como primeira escolha para sistemas novos — é memory-hard (mais resistente a ataques com GPU e ASIC), sem limite de comprimento de senha, e venceu o Password Hashing Competition em 2015. Bcrypt continua sendo uma escolha sólida para sistemas que já o usam, com cost factor 12 ou superior. Se você está começando do zero e sua linguagem/framework tem bom suporte a Argon2id, prefira Argon2id.

Recursos

• OWASP Password Storage Cheat Sheet — Guia autoritativo sobre algoritmos recomendados, cost factors e estratégias de migração.
• bcryptjs no GitHub — A biblioteca JavaScript pura que alimenta esta ferramenta — sem dependências nativas, roda em qualquer browser.