El algoritmo aburrido que sigue funcionando
bcrypt se diseñó en 1999. Es uno de los pocos algoritmos de seguridad de aquella época que sigue siendo un default aceptable en 2026.
Eso ya impresiona por sí solo. La mayoría de algoritmos “seguros” de hace veinticinco años están rotos o deprecated. bcrypt no. Sigue apareciendo arriba en casi todas las recomendaciones de almacenamiento de contraseñas, junto al más nuevo Argon2id.
La tentación es asumir que lo más nuevo es automáticamente mejor. No siempre. bcrypt tiene propiedades que vienen de la edad: está en cada lenguaje, lo soporta cada framework, cada ingeniero de devops se lo ha cruzado antes, y sus modos de fallo son bien conocidos. Aburrido es una característica.
Cómo funciona bcrypt sin entrar en matemáticas
bcrypt coge tu contraseña y un “factor de coste” que tú eliges, pasa la contraseña por una función lenta muchas veces, y saca una cadena de longitud fija que incluye el factor de coste dentro.
El factor de coste es exponencial. Coste 10 es el doble de lento que coste 9. Coste 12 es cuatro veces más lento que coste 10. Más coste igual a hash más lento igual a más dolor para un atacante que está probando miles de millones de hipótesis.
La salida tiene esta pinta: $2b$12$N9qo8uLOickgx2ZMRZoMye.... El 2b es la versión de bcrypt, el 12 es el factor de coste, y el resto es el salt y el hash. Todo lo que necesitas para verificar una contraseña más adelante está contenido en esa cadena. No guardas el coste ni el salt por separado.
Cuando el verificador comprueba un login, parsea el coste de la cadena guardada, ejecuta la misma operación, compara el resultado. Mismo input, mismo coste, misma respuesta.
El factor de coste en 2026
En 2026, el factor de coste correcto está entre 12 y 14, según tu hardware.
12 es el suelo. Cualquier cosa por debajo de 12 es demasiado barato para los atacantes actuales. 14 está bien si tus servidores pueden gastar la CPU. El número que quieres es el que tarda entre 250 y 500 ms por verificación en el hardware de producción. Más rápido y estás dejando margen sobre la mesa. Más lento y los logins se sienten colgados.
El ejercicio más útil: cronometra bcrypt a coste 12, 13 y 14 en tu servidor real, elige el más alto que se quede por debajo de 500 ms. Repite la prueba una vez al año conforme el hardware se hace más rápido.
bcrypt vs Argon2id: cuándo gana cada uno
Argon2id es el default moderno y la primera recomendación de OWASP. Es exigente en memoria (lo que deja a las tarjetas gráficas mucho menos útiles como hardware de ataque) y tiene análisis formal detrás.
bcrypt es más viejo, menos exigente en memoria, pero más curtido. Cada lenguaje tiene una librería que funciona, y no tienes que pensar en parámetros de memoria porque no los hay.
La comparación honesta:
- Código nuevo en 2026: Argon2id es probablemente la elección correcta.
- Código existente con bcrypt: quédate con bcrypt, sigue siendo defendible. Migra solo cuando estés haciendo una refactorización mayor.
- Entornos con memoria limitada: bcrypt, porque Argon2 quiere 32 a 64 MB por hash y bcrypt tira con kilobytes.
La elección incorrecta es migrar solo porque Argon2 es más nuevo. Migrar hashes de contraseñas es el tipo de cambio que se rompe de formas sutiles, y bcrypt a coste 13 no es el eslabón débil de tu modelo de seguridad.
Lo que todavía hace tropezar
Algunos errores comunes:
Truncar la contraseña. bcrypt tiene un límite de 72 bytes en el input. Si tus usuarios tienen passphrases muy largas, cualquier cosa pasados los 72 bytes se ignora silenciosamente. Las librerías modernas avisan o se niegan, las viejas truncan en silencio. Verifica el comportamiento de tu librería.
Reutilizar el mismo salt. Algunas integraciones caseras quitan el salt pensando que son bytes desperdiciados. Sin un salt por contraseña, dos usuarios con la misma contraseña obtienen el mismo hash, y la base de datos entera se vuelve atacable como un solo lote. Nunca modifiques la salida de bcrypt, guárdala tal cual.
Olvidarse de subir el coste. El coste que pusiste en 2018 es demasiado barato en 2026. El patrón correcto: en cada login exitoso, comprueba si el coste está por debajo de tu objetivo actual. Si lo está, rehashea y actualiza. Con el tiempo, cada cuenta activa se mueve al coste nuevo.
Comparar con ==. Usa la función verify de la librería bcrypt, no igualdad de strings. La función verify usa una comparación de tiempo constante que no filtra información por ataques de tiempo.
Una checklist práctica para 2026
Si tienes bcrypt hoy: quédate. Sube el coste a 12 o 13, añade el auto upgrade en login.
Si arrancas de cero: elige Argon2id con los parámetros del post de hash de contraseñas, a menos que tengas una razón específica para preferir bcrypt.
Si tienes algo peor (SHA-256, MD5, hash plano): migra. El patrón de envolver el hash legacy es el correcto, tanto bcrypt como Argon2 funcionan bien envolviendo un hash heredado.
Cuando necesites inspeccionar el formato de un hash guardado (sacar el coste, la versión, el salt), el generador de hash de AldeaCode corre en tu navegador y te enseña qué es cada pieza. El codificador Base64 ayuda cuando el hash viene codificado para transporte.
bcrypt no es emocionante. Tiene veinticinco años, las matemáticas no han cambiado, y hace el mismo trabajo aburrido que siempre hizo. Esa es exactamente la razón por la que sigue formando parte de la conversación.