Generador de Hash Bcrypt

Acerca de Generador de Hash Bcrypt

bcrypt es una función hash pensada específicamente para guardar contraseñas. A diferencia de los hashes rápidos como MD5 o SHA-256, lleva dentro un factor de coste que fija lo lenta que es la operación. Esta herramienta calcula el hash de una contraseña con una sal nueva ($2b$…) o verifica qué contraseña corresponde a un hash existente.

El resultado es una cadena de 60 caracteres con la forma $2b$10$…: una etiqueta de versión ($2b), un factor de coste (10), una sal base64 de 22 caracteres y un resumen base64 de 31, todo en una línea. Como la sal vive dentro de la cadena, no hay que guardarla aparte para verificar después. bcrypt no está en Web Crypto, así que se implementa en JS puro, y el cálculo pesado corre en un web worker para que la página no se congele.

El factor de coste es un exponente: 10 frente a 12

Un factor de coste c significa que la preparación interna de clave se ejecuta 2^c veces, así que cada aumento de uno duplica el trabajo. El coste 10 son 2^10 = 1.024 rondas, el 12 son 2^12 = 4.096 (cuatro veces más) y el 14 son 2^14 = 16.384 (dieciséis veces). Esta herramienta admite de 4 a 14 y usa 10 por defecto; 4 es el mínimo con el que sigue respondiendo en el hilo principal del navegador.

El coste adecuado depende de tu hardware. OWASP recomienda un factor de trabajo de 10 o más para sistemas heredados que deban usar bcrypt. Una referencia habitual es ajustarlo para que una verificación de inicio de sesión tarde entre 0,25 y 0,5 segundos en tu servidor. Subir el coste frena en la misma proporción a un atacante que trabaje sobre hashes filtrados, pero también ralentiza cada inicio de sesión real, así que súbelo tanto como tu servidor aguante.

Puedes subir el coste de hashes ya guardados más adelante: la próxima vez que el usuario entre, vuelve a calcular el hash de la contraseña escrita con el coste mayor y reemplaza el valor. Esa vía de actualización es lo que llevó al artículo original (Provos y Mazières, 1999) a llamar a bcrypt «adaptable al futuro».

El límite de 72 bytes: contraseñas largas y UTF-8

bcrypt solo usa los primeros 72 bytes de una contraseña; lo que sigue se ignora en silencio. La unidad son bytes, no caracteres. En ASCII es un byte por carácter, pero muchos no lo son: un emoji o un carácter CJK ocupa 3–4 bytes en UTF-8, así que una contraseña de esos caracteres se trunca mucho antes de los 72 caracteres. Esta herramienta te avisa cuando la entrada supera los 72 bytes.

Ese límite fue una vulnerabilidad real una vez. En octubre de 2024, Okta reveló que su autenticación delegada AD/LDAP formaba una clave de caché concatenando userId + username + password y pasándola por bcrypt. Cuando el nombre de usuario tenía 52 caracteres o más, la contraseña quedaba empujada más allá del límite de 72 bytes y se ignoraba, de modo que, en ciertas condiciones, cualquier contraseña pasaba. La lección: nunca antepongas otros datos antes de dar la contraseña a bcrypt.

Si necesitas incorporar del todo una contraseña o frase larga, puedes pre-hashear antes de bcrypt, pero con cuidado. OWASP advierte de que el pre-hash simple es peligroso por los bytes NULL y el «password shucking», y recomienda envolverlo como bcrypt(base64(hmac-sha384(contraseña, pepper))). Para un sistema nuevo es más limpio usar Argon2 y saltarse el rodeo.

$2a frente a $2b: por qué hay una letra de versión

El prefijo $2a$, $2b$, $2y$ es la versión del algoritmo. $2a es el original de 1999; en 2011 un fallo en cómo la implementación de OpenBSD manejaba caracteres de 8 bits llevó al corregido $2b. $2y era la marca de PHP para el mismo arreglo y es prácticamente idéntico a $2b. Esta herramienta genera $2b y, al verificar, conserva la letra de versión del hash original para la comparación.

Como el formato de la cadena bcrypt está estandarizado, los hashes hechos en otros entornos (PHP, el bcrypt de Node, passlib de Python) se verifican aquí, y los hechos aquí se verifican allí.

Misma contraseña, un hash distinto cada vez

Cada vez que generas se crea una sal aleatoria nueva de 16 bytes, así que la misma contraseña da un hash diferente cada vez. Es lo correcto y de hecho necesario: la sal hace que dos usuarios con la misma contraseña tengan hashes distintos y anula las tablas de búsqueda precalculadas (rainbow tables).

La verificación extrae la sal y el coste de la cadena, vuelve a calcular el hash de la contraseña introducida con los mismos parámetros y compara con una comprobación de tiempo constante que reduce los canales laterales de temporización. Así, sin saber nada más, una contraseña y un hash bastan para saber si coinciden.

Ejemplos

Cómo se usa

1. En la pestaña de generar, escribe una contraseña y elige un coste (4–14).
2. Genera para obtener un hash $2b$… con una sal nueva.
3. En la pestaña de verificar, introduce una contraseña y un hash bcrypt existente para comprobar la coincidencia.
4. Copia el resultado a tu base de datos o código.

Términos clave

Coste / factor de trabajo

Un exponente: la preparación interna corre 2^coste veces. Cada aumento de uno duplica el tiempo.

Sal

Un valor aleatorio de 16 bytes por hash. bcrypt la guarda dentro de la cadena del hash.

Límite de 72 bytes

El número máximo de bytes de contraseña que usa bcrypt; el resto se ignora.

Preguntas frecuentes

Guías relacionadas

• Cómo se guardan las contraseñas: del texto plano a Argon2