bcrypt Gerador de Hash
Ferramenta gratuita de bcrypt Gerador de Hash online. Processamento 100% local — seus dados nunca saem do seu dispositivo.
O resultado será exibido aqui...
Entrada → Calcular Hash
Usage Guide
Sobre o bcrypt
bcrypt é uma função de hash de senhas projetada por Niels Provos e David Mazières em 1999, baseada na cifra Blowfish. Foi especificamente construída para ser lenta e computacionalmente custosa, tornando os ataques de força bruta impraticáveis. bcrypt é um dos algoritmos de hash de senhas mais amplamente implantados no mundo, com suporte nativo em frameworks como Rails, Django, Laravel e Node.js (bcryptjs). Cada hash bcrypt incorpora um sal aleatório e o fator de custo, tornando o hash completamente autossuficiente para verificação.
Etapas de Uso
Esta ferramenta suporta duas operações: fazer hash de uma senha (Criptografar) e verificar uma senha contra um hash (Descriptografar):
Características do Algoritmo
bcrypt tem várias propriedades que o tornam adequado para armazenamento de senhas:
Guia do Fator de Custo
Escolher o fator de custo certo equilibra segurança versus desempenho do servidor:
FAQ
Q: Qual é o formato de saída do bcrypt?
A: Um hash bcrypt tem sempre exatamente 60 caracteres e parece: $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/lewdBdXyXu2zXpOme.
Detalhamento:$2b$: Identificador de versão bcrypt.12$: O fator de custo.
Próximos 22 caracteres: Sal aleatório de 128 bits codificado em Base64.
Últimos 31 caracteres: Hash derivado de 184 bits codificado em Base64.
Propriedade chave: Todos os parâmetros estão incorporados na string — nenhum armazenamento adicional é necessário para verificar uma senha posteriormente.
Q: Como o bcrypt se compara ao Argon2?
A: bcrypt (1999): computacionalmente difícil, ~4 KB memória, resistência GPU moderada, suporte universal. Argon2 (2015): difícil em memória (configurável, padrão 64 MB), resistência a ASIC/GPU muito mais forte, preferido pela OWASP e NIST. Quando usar bcrypt: Mantendo um sistema existente ou quando Argon2 ainda não está disponível. Quando usar Argon2: Todos os novos projetos.
Q: Por que o bcrypt não pode ser usado para fazer hash de arquivos ou dados grandes?
A: bcrypt tem um limite de entrada de 72 bytes. Caracteres além do 72º byte são silenciosamente ignorados. Para integridade de arquivos, use SHA-256 ou SHA-512. bcrypt é construído especificamente para senhas curtas inseridas por humanos apenas.
Q: O bcrypt é seguro se meu banco de dados for comprometido?
A: Sim — um hash bcrypt é unidirecional. Com cost=12, um único núcleo de CPU pode tentar aproximadamente 2–5 hashes por segundo, tornando ataques exaustivos contra senhas fortes efetivamente inviáveis. No entanto, bcrypt não protege senhas fracas — sempre aplique uma política mínima de força de senha.
Q: Qual fator de custo devo usar em produção?
A: Recomendação OWASP 2023: cost=12 como linha de base. Faça benchmark no seu servidor de produção e escolha o maior fator de custo que mantém o hash abaixo de 500 ms. Nunca vá abaixo de cost=10. Revise a cada 2–3 anos conforme o hardware melhora.
Q: O bcrypt pode ser usado para armazenamento de chaves API ou tokens?
A: Sim, com ressalvas. bcrypt é adequado para fazer hash de chaves API e tokens com menos de 72 bytes e verificados raramente. Para verificação de alta frequência, use uma abordagem rápida de SHA-256 + sal em vez disso.
Use Cases
Recomendado: Armazenamento de Senhas de Usuário
Este é o principal caso de uso do bcrypt. Faça hash com bcrypt (cost ≥ 12) e armazene a string de 60 caracteres. Durante o login, execute a verificação bcrypt. bcrypt é suportado nativamente em Rails (has_secure_password), Django, Laravel e Node.js (bcryptjs).
Recomendado: Compatibilidade com Sistemas Legados
Para sistemas que armazenam milhões de hashes bcrypt, continue usando bcrypt e aumente o fator de custo conforme o hardware melhora. Novos usuários podem atualizar transparentemente para Argon2id enquanto hashes bcrypt (identificados pelo prefixo $2b$) continuam sendo verificados corretamente.
- ✅ Manter bcrypt para hashes existentes — nenhuma migração forçada necessária
- ✅ Introduzir gradualmente Argon2id para senhas novas e atualizadas
- ✅ Usar detecção de prefixo de hash ($2b$ vs $argon2id$) para rotear verificação
- 💡 Registrar o algoritmo usado por usuário para acompanhar o progresso da migração
Aceitável: Hash de Chaves API
bcrypt pode fazer hash de chaves API antes do armazenamento no banco de dados. Para verificação por requisição em escala, prefira um esquema rápido HMAC-SHA256 ou um hash SHA-256 da chave.
- ✅ bcrypt (cost=10–12, bom para verificação de baixa frequência)
- ✅ SHA-256 + sal (mais rápido, adequado para chaves de alta entropia)
- ✅ HMAC-SHA256 (para assinatura de tokens por requisição)
- 💡 Usar prefixo de hash (primeiros 8 chars) como índice de banco de dados para busca rápida
Não Recomendado: Criptografia de Arquivos ou Dados
bcrypt é uma função hash unidirecional, não um algoritmo de criptografia. Não pode criptografar arquivos. Além disso, o limite de entrada de 72 bytes do bcrypt o torna inadequado para fazer hash de conteúdos de arquivos. Para criptografia de arquivos, use uma cifra simétrica (ex., AES-256-GCM).
- ❌ Não usar bcrypt para criptografia de arquivos (não é reversível)
- ❌ Não fazer hash de dados maiores que 72 bytes com bcrypt
- ✅ Usar AES-256-GCM para criptografia simétrica de arquivos
- ✅ Usar Argon2id ou scrypt para derivação de chaves baseada em senha
Não Recomendado: Hash Geral de Dados
bcrypt é muito lento para verificações de integridade de dados de propósito geral. Use SHA-256 ou SHA-512 para verificação de integridade.
- ❌ Não usar bcrypt para verificações de integridade de dados ou hash de conteúdo
- ✅ SHA-256 (hash de integridade de propósito geral)
- ✅ BLAKE2b (hash criptográfico de alta velocidade)
- ✅ SHA-3 / SHA-512 (maior margem de segurança)
Não Recomendado: Autenticação de Alta Frequência
bcrypt é projetado para ser lento (~200–500 ms em cost=12). Executá-lo em cada requisição API deixaria seu servidor de joelhos. Use bcrypt apenas uma vez no login — depois emita um JWT assinado para requisições subsequentes.
- ❌ Não executar bcrypt em cada requisição API
- ✅ JWT + HMAC-SHA256 (auth stateless, rápida por requisição)
- ✅ Session + Cookie (gerenciamento de sessão tradicional do lado do servidor)
- ✅ OAuth 2.0 / OpenID Connect (identidade federada, baseada em tokens)
Resumo de Melhores Práticas
- Usar bcrypt (cost ≥ 12) para armazenamento de senhas de usuário em sistemas existentes. Para novos projetos, preferir Argon2id.
- Nunca usar bcrypt para hash geral de dados, criptografia de arquivos ou dados maiores que 72 bytes.
- Fazer benchmark no hardware de produção e mirar em 200–500 ms por hash. Incrementar o fator de custo a cada 2–3 anos.
- Para cenários de auth de alta frequência, usar bcrypt apenas no login, depois emitir JWT ou tokens de sessão.
- Migração gradual do bcrypt para Argon2id: manter bcrypt para hashes existentes, usar Argon2id para novas senhas.