Generador de hash Bcrypt
Generá hashes Bcrypt para tus contraseñas con cost factor ajustable. Útil para testing, fixtures y comparar implementaciones. Todo se procesa en tu navegador.
Cost 10: ~100 ms por hash (servidor moderno)
Por qué Bcrypt en lugar de un SHA
SHA-256 es rápido por diseño: 100 millones de hashes por segundo en una GPU es habitual. Eso es una ventaja cuando hasheás archivos para verificar integridad, pero es un problema cuando hasheás contraseñas: un atacante puede probar miles de millones de candidatos por segundo contra una base filtrada.
Bcrypt resuelve esto siendo lento a propósito. Su factor de costo (también llamado work
factor o rounds) determina cuántas iteraciones del algoritmo Blowfish modificado se
ejecutan: 2^cost. Con cost 10, son 1024 iteraciones; con cost 12, son 4096.
Cada incremento duplica el tiempo necesario.
Cómo se ve un hash Bcrypt
El formato es $2a$10$abcdefghijklmnopqrstuv1234567890abcdefghijklmnopqrstu:
$2a$(o$2b$,$2y$): identificador de versión.10: el cost factor.- 22 caracteres siguientes: la sal (16 bytes en Base64 modificado).
- 31 caracteres restantes: el hash (24 bytes en Base64 modificado).
Toda esta información viaja con el hash. Por eso, al verificar una contraseña, no necesitás guardar la sal por separado: bcrypt la extrae del hash mismo.
Cost factor: cómo elegirlo
El cost factor es el equilibrio entre seguridad y tiempo de respuesta del login. Una guía aproximada para 2026:
- Cost 8-9: obsoleto. Solo para datos legacy.
- Cost 10: mínimo aceptable. ~100 ms por hash en un servidor moderno.
- Cost 12: recomendado para producción nueva. ~400 ms.
- Cost 13-14: alta seguridad. ~1-2 segundos por hash.
- Cost 15+: excesivo para login interactivo (latencia molesta).
Una buena práctica es subir el cost factor cada 1-2 años. La forma más práctica es rehashear la contraseña del usuario al login: si el cost actual es menor que el objetivo, calculás el hash nuevo y lo guardás.
Sal y resistencia a rainbow tables
Cada hash bcrypt incluye una sal aleatoria de 16 bytes generada al momento de crear el hash. La consecuencia: hashear la misma contraseña dos veces produce hashes distintos. Eso impide los ataques con rainbow tables (tablas pre-computadas de hash a contraseña), porque el atacante tendría que generar una rainbow table por cada sal.
Bcrypt vs argon2id vs scrypt
- Bcrypt (1999): ampliamente adoptado, librerías estables en todos los lenguajes. Limitado: solo 72 bytes de password y no es resistente a ASIC.
- scrypt (2009): añade requisitos de memoria, lo que dificulta ASICs. Usado en algunas criptomonedas y en LastPass.
- argon2id (2015): ganador del Password Hashing Competition. Configurable en CPU, memoria y paralelismo. Recomendación actual del OWASP para nuevas aplicaciones.
Si estás empezando un proyecto nuevo, usá argon2id. Si tu stack tiene bcrypt implementado de toda la vida, mantenerlo con cost 12+ es perfectamente seguro hoy.
Errores frecuentes con Bcrypt
- Usarlo para algo que no son contraseñas. Bcrypt no sirve como hash de archivos ni de identificadores: para eso, SHA-256.
- Limitar la contraseña a menos de 72 bytes. Bcrypt trunca a 72 bytes silenciosamente. Validá la longitud antes.
- Cost factor demasiado bajo. Cost 6 o 7 era razonable hace 15 años. Hoy se rompe en horas.
- Implementación propia. Nunca implementes bcrypt vos: usá la librería oficial de tu lenguaje. Este generador es solo para testing.
Preguntas frecuentes
¿Qué es Bcrypt?
Una función de hashing diseñada para contraseñas. Lenta a propósito: dificulta los ataques de fuerza bruta incluso con GPUs.
¿Qué cost factor elegir?
En 2026, 12 es el mínimo razonable y 13-14 es lo recomendado. Cada incremento duplica el tiempo.
¿Bcrypt o argon2?
Argon2id es más moderno y resistente a hardware especializado. Bcrypt sigue siendo aceptable; argon2id es preferible para nuevas implementaciones.
¿Es seguro hashear en el navegador?
Para testing y desarrollo, sí. En producción, hasheá en el servidor con la librería oficial de tu lenguaje.