Se você precisa armazenar senhas de forma segura, o Bcrypt é uma das escolhas mais recomendadas. Ele aplica um algoritmo de hashing adaptativo que inclui salting e fator de custo, dificultando ataques de força bruta e com dicionário. Neste artigo, você vai aprender as melhores práticas para usar o Bcrypt, erros frequentes que comprometem a segurança e alternativas como PBKDF2 e Argon2.

O que é Bcrypt e por que usá-lo?

Bcrypt é uma função de hashing de senhas baseada no cifra Blowfish. Ela foi projetada para ser lenta e computacionalmente cara, o que é desejável para proteção contra ataques offline. Cada hash gerado contém automaticamente um salt aleatório, eliminando a necessidade de gerenciar salts separadamente. Além disso, o fator de custo (cost factor) permite aumentar a dificuldade conforme o hardware evolui, mantendo a segurança ao longo do tempo.

No contexto do nosso Bcrypt, você pode gerar e verificar hashes diretamente no navegador, sem enviar dados para servidores. Isso é especialmente útil quando a privacidade é uma preocupação – a ferramenta foi planejada para uso local no cliente. No entanto, vale notar que o Bcrypt é pesado para JavaScript, e por isso disponibilizamos também uma variante usando PBKDF2-SHA256 como substituto browser-safe, mais rápida em execução no navegador, porém igualmente segura quando bem configurada.

Boas práticas para usar Bcrypt

1. Escolha um fator de custo adequado

O fator de custo (cost ou rounds) determina quantas iterações o algoritmo executa. Quanto maior, mais lento o hash. O valor padrão é 10, mas você deve ajustá-lo de acordo com a potência do seu servidor e a tolerância a atrasos na autenticação. Uma boa prática é testar diferentes valores e escolher o maior que ainda mantenha a resposta em menos de 250 ms. Por exemplo:

``javascript const bcrypt = require('bcrypt'); const saltRounds = 12; // ajuste conforme necessário const hash = await bcrypt.hash('minhaSenha', saltRounds); ``

Com o aumento da capacidade computacional, reavalie periodicamente o custo. Hashes antigos podem ser atualizados durante o próximo login, usando o novo fator.

2. Sempre gere um novo salt para cada senha

Nunca reutilize salts. O Bcrypt gera salts automaticamente quando você chama a função de hash – aproveite isso. Se por algum motivo você precisar usar um salt fixo, estará quebrando a segurança. A reutilização de salts permite ataques com tabelas rainbow e pré-computação.

3. Armazene o hash completo, incluindo metadados

O resultado do Bcrypt é uma string que contém o algoritmo, o fator de custo, o salt e o hash propriamente dito, tudo em um único campo. Por exemplo:

`` $2b$12$P1r7F8m3Kj9L0QwXyZ2A.uN5tH6vB7cD8eF9gH0iJ1kL2mN3oP4qR5sT ``

Salve exatamente essa string no banco de dados, sem dividir partes. Ao verificar, use bcrypt.compare() que extrai automaticamente os metadados.

4. Use o Bcrypt apenas em back-end confiável

Embora nossa ferramenta Bcrypt funcione no navegador, a recomendação oficial é realizar o hashing no servidor. Processos no cliente podem expor o algoritmo e o salt, além de depender do JavaScript do usuário. Use a versão browser apenas para testes ou quando não há outra opção. Em produção, prefira bibliotecas server-side como bcrypt para Node.js, bcrypt-ruby ou python-bcrypt.

5. Combine com outras camadas de segurança

O hashing não é a única defesa. Adote HTTPS, autenticação multifator (MFA), limitação de tentativas de login e monitoramento de acessos suspeitos. O Bcrypt protege contra vazamento de hashes, mas não impede ataques de força bruta online.

Erros comuns ao usar Bcrypt

1. Usar fator de custo muito baixo

Valores abaixo de 10 são considerados inseguros atualmente. Muitos tutoriais antigos sugerem 4 ou 6 – isso permite que GPUs modernas quebrem a senha rapidamente. Sempre use pelo menos 10 e idealmente 12 ou mais.

2. Armazenar senhas em texto puro ou com hash simples (MD5, SHA-1)

Ainda é surpreendentemente comum encontrar sistemas que armazenam senhas com hash rápido. Isso é inaceitável hoje. O Bcrypt foi projetado justamente para ser lento. Nunca substitua por SHA-256 ou MD5 sem sal.

3. Ignorar a validação de senhas no front-end

Embora o hash seja server-side, validar requisitos mínimos (tamanho, complexidade) no cliente evita sobrecarregar o servidor com requisições inválidas. Faça uma validação básica antes de enviar a senha.

4. Esquecer de atualizar hashes antigos quando o custo aumenta

Se você aumentar o fator de custo no servidor, hashes antigos continuarão com o custo baixo. Durante o login, quando a senha for verificada com sucesso, recalcule o hash com o novo custo e atualize no banco.

5. Confiar cegamente em bibliotecas desatualizadas

Mantenha as bibliotecas de Bcrypt sempre atualizadas. Versões antigas podem conter vulnerabilidades ou implementações incorretas. Verifique regularmente por atualizações de segurança.

Alternativas ao Bcrypt

Embora o Bcrypt seja excelente, existem outras funções modernas:

  • PBKDF2: Padrão do NIST, utiliza HMAC com SHA-256 ou SHA-512. É nativo em muitas linguagens. No entanto, por ser menos resistente a ataques com GPU quando comparado ao Bcrypt (que tem maior consumo de memória), recomenda-se usar um número grande de iterações (ex: 600.000 para SHA-256). Em nosso Bcrypt, oferecemos também PBKDF2-SHA256 como alternativa browser-safe, por ser mais leve para JavaScript.
  • Argon2: Vencedor do Password Hashing Competition (2015). É o mais seguro atualmente, pois é resistente a ataques de GPU e ASIC, além de permitir ajuste de memória, tempo e paralelismo. Para novos sistemas, prefira Argon2id.
  • scrypt: Similar ao Argon2, com foco em uso intensivo de memória. Menos popular hoje, mas ainda seguro.

A escolha depende do seu ambiente: se você precisa de compatibilidade máxima, PBKDF2 é seguro; se busca o estado da arte, vá de Argon2; Bcrypt é o equilíbrio entre segurança e adoção consolidada.

Perguntas frequentes

1. Qual fator de custo devo usar no Bcrypt?

Recomenda-se um valor entre 10 e 12 para servidores comuns. Ajuste com base em testes: o hash deve levar entre 100 e 250 ms para ser gerado.

2. Posso usar Bcrypt em JavaScript no navegador?

Sim, mas não é ideal para produção. O Bcrypt consome muitos recursos do cliente e pode travar a interface. Oferecemos uma implementação que também suporta PBKDF2-SHA256, mais adequada ao navegador.

3. O Bcrypt é seguro contra ataques de força bruta?

Sim, desde que o fator de custo seja alto o suficiente. A cada iteração o custo dobra, tornando inviável testar bilhões de senhas.

4. Preciso armazenar o salt separadamente no banco de dados?

Não. O Bcrypt inclui o salt no próprio hash. A função bcrypt.compare() extrai automaticamente o salt.

5. Argon2 substitui o Bcrypt?

Em novos projetos, sim. Argon2 é mais seguro e flexível. Porém, o Bcrypt ainda é uma excelente opção e muito utilizado em sistemas legados. A migração pode ser feita gradualmente.

Conclusão

O Bcrypt continua sendo uma ferramenta confiável e amplamente adotada para hashing de senhas, desde que usado com boas práticas: fator de custo adequado, salt automático, armazenamento correto e combinação com outras medidas de segurança. Evite os erros comuns e considere alternativas como PBKDF2 ou Argon2 quando necessário. Em nossa [categoria de ferramentas crypto](/), você encontra recursos para gerar e testar hashes com segurança. Lembre-se: nenhuma solução oferece segurança absoluta, mas seguir estas diretrizes reduz drasticamente os riscos.