Gerador de hash bcrypt para senhas
O bcrypt foi criado para armazenar senhas: propositalmente lento, e com salt automático, para que duas senhas idênticas nunca produzam o mesmo hash.
Lendo essa string estranha que ele te dá
Um hash bcrypt parece ruído de linha, mas tem uma anatomia fixa que vale a pena conhecer. Ele começa com um marcador de versão como $2a$ ou $2b$, seguido pelo fator de custo que você escolheu, depois vinte e dois caracteres do salt aleatório e, por fim, os trinta e um caracteres do hash em si. Tudo o que um verificador precisa viaja dentro dessa única string — por isso o conjunto inteiro cabe em uma única coluna de banco de dados, e por isso gerar um hash para a mesma senha duas vezes dá duas strings diferentes, que mesmo assim são ambas válidas. O salt muda a cada vez, então a saída muda a cada vez; quando o seu backend depois verifica um login, ele lê o salt de volta a partir da string armazenada, faz o hash da tentativa com ele e compara o resultado.
Onde você realmente usaria esta página
Na maior parte do tempo, o hash bcrypt acontece dentro da sua aplicação, não em um navegador — mas há momentos em que um hash feito à mão é exatamente o que você precisa. Popular um banco de dados de teste com contas cujas senhas você conhece. Resgatar uma conta de administrador bloqueada escrevendo um hash novo direto na tabela de usuários. Verificar que formato de string uma biblioteca vai gerar antes de dimensionar a coluna para ela. Em todos esses casos, você cola uma senha, copia o hash e o coloca onde o seu código de login espera um. Uma coisa que nunca se deve fazer: comparar hashes como strings no seu próprio código. Por causa do salt, a mesma senha produz hashes diferentes — a verificação precisa passar pela função de comparação da sua biblioteca, que sabe como ler o salt de volta.
Escolhendo um custo com o qual você consegue conviver
Cada passo no fator de custo dobra o trabalho, tanto para você quanto para um atacante. Oito é rápido e é melhor deixar apenas para compatibilidade com sistemas legados; dez, o padrão aqui, é a escolha comum em produção; doze compra conforto quando os logins são raros; catorze leva segundos até para gerar. Um aviso justo sobre tempo: esta página roda uma implementação em JavaScript puro, que é mais lenta que o código nativo no seu servidor, então trate o atraso que você sente aqui como um limite superior, e não como um benchmark — meça na máquina que vai realmente cuidar dos logins. E, já que um hash só é tão bom quanto o que entra nele, o gerador de senhas cria uma entrada forte, enquanto qualquer coisa que não seja uma senha — arquivos, documentos, texto simples — pertence ao gerador de hash SHA.
Por que bcrypt em vez de um hash simples
Um hash SHA simples de uma senha pode ser quebrado por força bruta rapidamente em hardware moderno. O bcrypt é propositalmente lento — o fator de custo controla exatamente o quão lento — e aplica salt automaticamente, então a mesma senha nunca produz o mesmo hash armazenado duas vezes. É por isso que ele continua sendo uma escolha padrão para armazenar senhas no lado do servidor.
Qual fator de custo devo usar?
10–12 é um padrão comum em 2026 — alto o suficiente para resistir a força bruta, baixo o suficiente para não deixar os logins reais visivelmente mais lentos. Fatores de custo mais altos são mais seguros, mas mais lentos de calcular a cada login.
Posso usar isso para gerar o hash de um documento ou texto longo?
Não — o bcrypt trunca a entrada além de cerca de 72 bytes e foi projetado especificamente para senhas. Para gerar hashes de texto ou arquivos em geral, use o gerador de hash SHA.
Minha senha é enviada para algum lugar?
Não — a geração do hash acontece inteiramente no seu navegador, com JavaScript. Nada é enviado.
