Saltar al contenido principal

bcrypt - Hash de contraseñas probado por el tiempo

Lectura de 2 min aprox.

bcrypt es una función de hash de contraseñas basada en el cifrado Blowfish, diseñada en 1999 por Niels Provos y David Mazières. Su característica distintiva es un diseño que permite aumentar exponencialmente el costo computacional ajustando el factor de costo (factor de trabajo), lo que permite elevar el nivel de seguridad al ritmo de las mejoras en el rendimiento del hardware. Lleva más de 25 años en uso generalizado y, aun ahora que ha aparecido Argon2, sigue siendo un algoritmo muy fiable que ocupa el segundo lugar en la lista de recomendaciones de OWASP.

Antecedentes históricos

Antes de que apareciera bcrypt, los sistemas Unix usaban la función crypt basada en DES para el hash de contraseñas. Sin embargo, a finales de la década de 1990 la aceleración de las CPU hizo que el costo computacional de crypt fuera insuficiente, y los ataques de diccionario y los ataques de fuerza bruta se convirtieron en amenazas realistas. Provos y Mazières diseñaron bcrypt como parte del proyecto OpenBSD y establecieron el concepto de una función hash adaptativa que «sigue siendo segura incluso en el hardware del futuro». Esta filosofía de diseño fue heredada después por scrypt y Argon2.

Cómo funciona el factor de costo

El factor de costo de bcrypt se especifica como un número entero de 4 a 31 y, internamente, realiza 2 elevado al factor de costo iteraciones. Aumentar el factor de costo en 1 duplica aproximadamente el tiempo de cómputo.

Factor de costoIteracionesTiempo de procesamiento aproximadoUso
101,024Unos 100 msMínimo aceptable
124,096Unos 400 msRecomendado por OWASP (2025)
1416,384Unos 1,5 segundosEntornos de alta seguridad

En la práctica, se elige el mayor factor de costo cuya latencia de procesamiento de inicio de sesión se mantenga dentro de un rango aceptable (normalmente de 250 ms a 1 segundo). Se recomienda revisar periódicamente y aumentar el factor de costo conforme al rendimiento de la CPU del servidor.

Generación automática de sal y formato de almacenamiento

bcrypt genera automáticamente una sal de 128 bits y la almacena junto con el valor hash como una única cadena. Una gran ventaja práctica es que los desarrolladores no necesitan implementar por separado la generación ni la gestión de la sal.

$2b$12$LJ3m4ys3Lg7Ey6yGqV8sZeKxYBCfGJZiNL5.mDHbgA7cWyPCkxbC6
├ $2b$ ... versión del algoritmo
├ 12$ ... factor de costo
├ LJ3m4ys3Lg7Ey6yGqV8sZe ... sal (22 caracteres)
└ KxYBCfGJZiNL5.mDHbgA7cWyPCkxbC6 ... valor hash (31 caracteres)

Comparación con Argon2

La mayor diferencia entre bcrypt y Argon2 es si son resistentes a la memoria (memory-hard). bcrypt es una función limitada por CPU y no exige grandes cantidades de memoria para su cálculo. Por ello, ofrece menos resistencia que Argon2 frente a ataques que ejecutan cálculos hash en paralelo en GPU con miles de núcleos. Para sistemas nuevos, Argon2id es la primera opción, pero en sistemas donde bcrypt ya está implantado no es necesario migrar de inmediato siempre que el factor de costo esté configurado adecuadamente. Al migrar, el enfoque habitual es volver a calcular el hash en el siguiente inicio de sesión. El diseño general del almacenamiento de contraseñas se explica en la guía de gestión segura de contraseñas.

Advertencias sobre el límite de 72 bytes

bcrypt tiene la limitación de que la contraseña de entrada se trunca a 72 bytes. En la codificación UTF-8, un solo carácter japonés consume 3 bytes, por lo que para una contraseña compuesta únicamente de caracteres japoneses el límite superior efectivo es de 24 caracteres. Con una mezcla de caracteres alfanuméricos, son válidos hasta 72 caracteres, pero todo lo que exceda se ignora. Para sortear este límite existe la técnica de aplicar previamente un hash SHA-256 a la contraseña antes de pasarla a bcrypt, pero requiere una implementación cuidadosa por escollos como el problema del byte nulo. Tenga en cuenta este límite al diseñar una política de contraseñas.libros sobre seguridad de contraseñas (Amazon) para aprender los detalles de implementación.

Conceptos erróneos comunes

La percepción de que «bcrypt es antiguo, por lo que es peligroso» no es exacta. No se ha encontrado ninguna vulnerabilidad fatal en bcrypt en sí, y operado con un factor de costo adecuado (12 o superior) proporciona seguridad suficiente incluso en 2025. Lo que se convierte en un problema es cuando el factor de costo es demasiado bajo (inferior a 10) o cuando se sigue usando una implementación antigua que contiene errores de biblioteca. La evolución histórica del hash de contraseñas también se presenta en el artículo sobre la historia y cultura de las contraseñas. Para los fundamentos de la criptografía, consulte los fundamentos del cifrado.

Términos relacionados

¿Te resultó útil este artículo?

XHatena