Generador y verificador de hash bcrypt

Niels Provos e David Mazières criaram o bcrypt em 1999 como parte do sistema OpenBSD, publicando o artigo 'A Future-Adaptable Password Scheme' — um título que envelheceu muito bem. O problema que eles queriam resolver era óbvio mas frequentemente ignorado na época: MD5 e SHA-1 foram projetados para ser rápidos, o que é exatamente o oposto do que você quer ao proteger senhas. Uma GPU moderna executa centenas de bilhões de hashes MD5 por segundo — o que torna ataques de força bruta offline devastadores quando um banco de dados é comprometido. Antes do bcrypt se popularizar, era comum encontrar senhas armazenadas como MD5 puro, às vezes sem sal. A violação da Adobe em 2013 expôs 153 milhões de contas com senhas em MD5 com sal estático por grupo de senha idêntica — em poucas horas, ferramentas de cracking quebraram a maior parte das senhas comuns.

A inovação central do bcrypt é o fator de custo: um parâmetro que controla quantas rodadas do algoritmo Blowfish são executadas internamente (2^custo). Fator 10 leva cerca de 100 ms por hash numa CPU moderna; fator 12, cerca de 400 ms; fator 14, 1,6 segundos. Esse parâmetro pode ser aumentado conforme o hardware evolui, sem precisar migrar todos os hashes existentes — novos logins simplesmente usam o novo custo, e hashes antigos continuam funcionando com o custo em que foram gerados. O hash bcrypt completo é autocontido: `$2a$12$[22 chars salt][31 chars hash]`. O prefixo `$2a$` identifica a versão, o `12` é o custo, os 22 caracteres seguintes são o sal gerado aleatoriamente e os 31 restantes são o hash resultante. Você nunca precisa guardar o sal separadamente — ele já está no hash. O OWASP recomenda mínimo fator 10, com 12 sendo um bom equilíbrio entre segurança e tempo de resposta em 2024.

Esta ferramenta é útil para quem precisa depurar fluxos de autenticação: verificar se uma senha específica bate com um hash bcrypt armazenado sem precisar executar código — útil ao investigar bug de login ou ao validar dados migrados de outro sistema. Uma observação sobre o ecossistema: o bcrypt domina em PHP (`password_hash()` usa bcrypt como padrão desde PHP 5.5), Python (biblioteca `bcrypt`), Node.js (`bcryptjs`) e Ruby (gem `bcrypt`). Para sistemas novos em 2024, o OWASP e o NIST recomendam Argon2id como primeira escolha — vencedor da Password Hashing Competition de 2015, resistente a aceleração por GPU e por hardware especializado (ASICs). Mas o bcrypt ainda é perfeitamente adequado para a maioria das aplicações e tem 25 anos de uso em produção sem quebras práticas conhecidas.

Niels Provos and David Mazières created bcrypt in 1999 as part of the OpenBSD system, publishing the paper 'A Future-Adaptable Password Scheme' — a title that has aged remarkably well. The problem they wanted to solve was obvious but frequently ignored at the time: MD5 and SHA-1 were designed to be fast, which is exactly the opposite of what you want when protecting passwords. A modern GPU can run hundreds of billions of MD5 hashes per second — making offline brute-force attacks devastating when a database is compromised. Before bcrypt became widespread, it was common to find passwords stored as plain MD5, sometimes without any salt. The Adobe breach of 2013 exposed 153 million accounts with passwords stored as MD5 with a static salt shared by identical passwords — within hours, cracking tools had broken most of the common passwords.

The central innovation of bcrypt is the cost factor: a parameter that controls how many rounds of the Blowfish algorithm are executed internally (2^cost). Cost factor 10 takes about 100 ms per hash on modern CPU hardware; cost 12, about 400 ms; cost 14, 1.6 seconds. This parameter can be raised as hardware improves, without having to migrate all existing hashes — new logins simply use the new cost, and old hashes continue working with the cost at which they were generated. The full bcrypt hash string is self-contained: `$2a$12$[22-char salt][31-char hash]`. The `$2a$` prefix identifies the version, `12` is the cost factor, the following 22 characters are the randomly generated salt, and the remaining 31 are the resulting hash. You never need to store the salt separately — it is already embedded in the hash string. OWASP recommends a minimum cost factor of 10, with 12 being a good balance between security and response time in 2024.

This tool is useful for anyone who needs to debug authentication flows: verify whether a specific password matches a stored bcrypt hash without running code — handy when investigating a login bug or validating data migrated from another system. A note on the ecosystem: bcrypt dominates in PHP (`password_hash()` uses bcrypt as default since PHP 5.5), Python (the `bcrypt` library), Node.js (`bcryptjs`), and Ruby (the `bcrypt` gem). For new systems in 2024, OWASP and NIST recommend Argon2id as the first choice — winner of the 2015 Password Hashing Competition, resistant to GPU acceleration and specialized hardware (ASICs). But bcrypt remains perfectly adequate for most applications and has 25 years of production use without any known practical breaks.

Niels Provos y David Mazières crearon bcrypt en 1999 como parte del sistema OpenBSD, publicando el artículo 'A Future-Adaptable Password Scheme' — un título que ha envejecido muy bien. El problema que querían resolver era obvio pero frecuentemente ignorado en aquella época: MD5 y SHA-1 fueron diseñados para ser rápidos, lo que es exactamente lo contrario de lo que quieres al proteger contraseñas. Una GPU moderna puede ejecutar cientos de miles de millones de hashes MD5 por segundo — lo que hace devastadores los ataques de fuerza bruta offline cuando una base de datos queda comprometida. Antes de que bcrypt se popularizara, era habitual encontrar contraseñas almacenadas como MD5 puro, a veces sin sal. La brecha de Adobe en 2013 expuso 153 millones de cuentas con contraseñas en MD5 con sal estática compartida entre contraseñas idénticas — en pocas horas, las herramientas de cracking habían roto la mayoría de las contraseñas comunes.

La innovación central de bcrypt es el factor de coste: un parámetro que controla cuántas rondas del algoritmo Blowfish se ejecutan internamente (2^coste). El factor de coste 10 tarda unos 100 ms por hash en una CPU moderna; el factor 12, unos 400 ms; el factor 14, 1,6 segundos. Este parámetro puede incrementarse conforme el hardware evoluciona, sin necesidad de migrar todos los hashes existentes — los nuevos inicios de sesión simplemente usan el nuevo coste, y los hashes antiguos siguen funcionando con el coste con el que fueron generados. El string completo de bcrypt es autocontenido: `$2a$12$[22 chars sal][31 chars hash]`. El prefijo `$2a$` identifica la versión, el `12` es el factor de coste, los 22 caracteres siguientes son la sal generada aleatoriamente y los 31 restantes son el hash resultante. Nunca necesitas guardar la sal por separado — ya está incrustada en el string del hash. OWASP recomienda un factor de coste mínimo de 10, siendo 12 un buen equilibrio entre seguridad y tiempo de respuesta en 2024.

Esta herramienta es útil para quien necesita depurar flujos de autenticación: verificar si una contraseña específica coincide con un hash bcrypt almacenado sin necesidad de ejecutar código — muy práctico al investigar un error de inicio de sesión o al validar datos migrados desde otro sistema. Una nota sobre el ecosistema: bcrypt domina en PHP (`password_hash()` usa bcrypt como predeterminado desde PHP 5.5), Python (librería `bcrypt`), Node.js (`bcryptjs`) y Ruby (gem `bcrypt`). Para sistemas nuevos en 2024, OWASP y NIST recomiendan Argon2id como primera opción — ganador del Password Hashing Competition de 2015, resistente a aceleración por GPU y hardware especializado (ASICs). Pero bcrypt sigue siendo perfectamente adecuado para la mayoría de las aplicaciones y cuenta con 25 años de uso en producción sin ninguna ruptura práctica conocida.