Generador y verificador de bcrypt
Genera el hash bcrypt de una contraseña para el seed o la migración de tu usuario de prueba, o comprueba si una contraseña coincide con el hash guardado en la base de datos. Coste configurable, prefijos $2b$, $2a$ y $2y$, y el cálculo corre en segundo plano, sin bloquear la página.
Úsalo para datos de prueba, seeds y depuración de login. La contraseña es la que tú escribes: esta página no crea contraseñas.
Cada punto más duplica el tiempo. De 10 a 12 es lo habitual en producción; 4 hace rápidos los tests automatizados.
Estimación en este dispositivo: midiendo…
Estándar actual. Node (bcrypt, bcryptjs), Python y Go.
Los tres generan el mismo hash para la misma contraseña y salt; solo cambia la etiqueta. Usa el que guarda tu sistema para que el seed quede igual que los demás registros.
Escribe una contraseña para generar el hash.
¿Necesitas MD5 o SHA-256 para un checksum y no para una contraseña? Usa el generador de hash.
Qué es bcrypt
bcrypt es un algoritmo de hash de contraseñas creado en 1999, basado en el cifrado Blowfish. Sortea un salt de 16 bytes para cada contraseña y repite el trabajo 2 elevado al coste veces. El resultado guarda todo lo necesario para verificar después: prefijo, coste, salt y hash, en un texto de 60 caracteres. Por eso la misma contraseña genera un hash distinto cada vez, y la verificación usa el salt que va dentro del propio hash.
Por qué no MD5 ni SHA-256 para contraseñas
MD5 y SHA-256 se diseñaron para ser rápidos: una tarjeta gráfica prueba miles de millones por segundo. Si la base de datos se filtra, las contraseñas comunes aparecen en minutos. bcrypt es lento a propósito. Con coste 12, cada intento tarda decenas de milisegundos, lo que no pesa en un login y hace inviable probar millones de contraseñas. Un salt fijo para todo el sistema no resuelve nada, porque el atacante solo tiene que rehacer la tabla una vez.
Cómo elegir el coste
El coste es el exponente: 10 hace 1.024 rondas, 12 hace 4.096. Elige el valor más alto que tu servidor aguante sin que el login sea lento, y súbelo con el tiempo. En tests automatizados, coste 4 hace rápida la suite sin cambiar la lógica, siempre que el código de producción lea el coste de la configuración. El hash guarda su coste, así que las contraseñas antiguas siguen validando tras el cambio.
El límite de 72 bytes
bcrypt solo usa los primeros 72 bytes de la contraseña e ignora el resto sin avisar. Son bytes en UTF-8, no caracteres: ñ y á cuentan 2, un emoji cuenta 4. Algunas bibliotecas rechazan contraseñas más largas, otras las cortan. Si tu sistema acepta frases largas, limita el tamaño en el registro o aplica un hash antes, como hace Django.
$2a$, $2b$ y $2y$
$2a$ es la versión de 1999. En 2011 un bug en la implementación de PHP dio origen a $2y$, que marca los hashes correctos, y en 2014 OpenBSD corrigió un error con contraseñas de más de 255 bytes y creó $2b$. Hoy las bibliotecas tratan los tres como equivalentes: un hash $2y$ de Laravel valida en Node, y un $2a$ de Spring valida en Python. Esta página verifica los tres.
Usuarios de prueba en seeds y migraciones
Genera el hash aquí y guarda el valor listo en el seed, en lugar de llamar a la biblioteca en cada ejecución. Así el seed es determinista y rápido. Guarda la contraseña en texto solo en la documentación del entorno de pruebas, nunca en el repositorio de producción. Y revisa el tamaño de la columna: el hash tiene 60 caracteres, y VARCHAR(255) evita problemas si el algoritmo cambia en el futuro.
Preguntas frecuentes sobre bcrypt
Coste, prefijos, límite de 72 bytes y qué revisar cuando el login falla.