Calculadora del factor de coste de bcrypt | Mide tu CPU real, no copies una tabla genérica

La recomendación habitual de OWASP («usa coste 12») y las tablas de velocidad que circulan en blogs son un buen punto de partida, pero fueron escritas para el hardware de otra persona. El factor de coste correcto depende de la CPU concreta que ejecuta tu producción, del contenedor en el que vive y del patrón de tráfico que recibe. Esta página ejecuta bcryptjs en tu propio navegador, factor a factor, hasta encontrar el más alto que aún cabe dentro del presupuesto de latencia de inicio de sesión que tú indiques.

💡 Sobre esta herramienta

Cada vez que subes un escalón el factor de coste de bcrypt, el trabajo necesario se duplica. Si el coste 10 tarda 50 ms en una máquina, el coste 12 tardará unos 200 ms y el coste 14 unos 800 ms. Ese crecimiento exponencial es lo que da a bcrypt su resistencia frente a ataques de fuerza bruta, pero también significa que equivocarse en uno o dos puntos te deja con un login lento o con un almacenamiento de contraseñas más débil de lo que pensabas.

La medición recorre del coste 4 hasta el techo que elijas, hace un hash con bcryptjs en cada uno y muestra el tiempo medido en cada fila. Se destaca el coste más alto que aún cabe en tu tiempo objetivo y, justo debajo, aparece el prefijo $2b$NN$ listo para copiar — ese es el prefijo exacto que llevarán los hashes guardados, así que puedes pegarlo en una prueba unitaria o en el README del despliegue. Si una fila supera los 8 segundos, la ejecución se corta sola para que una laptop ARM lenta no se quede congelada medio minuto.

El texto que escribes en «contraseña de muestra» solo se pasa a bcrypt.hash() dentro de tu navegador. No se envía a ningún sitio, pero aun así no conviene pegar una contraseña real de producción en un campo de prueba; basta con el valor por defecto o cualquier cadena descartable.

🧐 Preguntas Frecuentes

Q. ¿Qué factor de coste tiene sentido en sistemas latinoamericanos donde el hardware varía mucho entre regiones? A. La regla general no cambia: medir en la máquina que ejecuta la producción. Si tu API corre en un VPS en São Paulo de 1 vCPU y tu backup está en Buenos Aires con un perfil distinto, conviene benchmarkear ambos: el factor recomendado debería ser el del nodo más lento, porque ahí es donde se sentirá la latencia bajo carga. Para muchos despliegues económicos en la región el resultado real suele caer entre coste 10 y 12.

Q. ¿bcrypt sigue valiendo la pena o paso directamente a Argon2id? A. Para sistemas nuevos, Argon2id es la primera opción recomendada por OWASP — es memory-hard y mejor protegido frente a ataques con GPU. bcrypt sigue siendo razonable cuando el ecosistema te lo exige: PHP password_hash() por defecto, Rails Devise, ASP.NET Identity, Laravel. Esta herramienta resuelve el problema realista de «ya estamos en bcrypt, ¿qué coste ponemos?», no la pregunta teórica de «¿qué algoritmo elegir desde cero?».

Q. La primera fila de la tabla aparece rara — ¿hay un error? A. El primer bcrypt.hash() paga el calentamiento del JIT de V8 y la carga del módulo desde esm.sh, así que el dato suele ser ruidoso. Pulsa de nuevo «Ejecutar medición» y confía en la segunda pasada para decisiones de frontera. Variaciones del 5 al 10 % entre ejecuciones son normales: bcryptjs es JavaScript de un solo hilo, no código nativo de tiempo constante.

Q. Si subo el coste, ¿los usuarios actuales pierden su contraseña? A. No. El coste viene grabado dentro de cada hash ($2b$10$... vs $2b$12$...), así que los hashes antiguos se siguen validando con su coste original. Lo recomendable es rehasear al iniciar sesión: cuando el usuario se autentica bien, comprueba bcrypt.getRounds() y si está por debajo del nuevo objetivo, vuelve a hashear con el coste nuevo y sobrescribe. Así la transición se reparte entre semanas de tráfico normal.

Q. ¿Por qué el coste mide 12 o 13 en mi MacBook y solo 10 en mi VPS? A. Apple Silicon hace bcrypt anormalmente rápido por su jerarquía de memoria. Un coste calibrado en Mac casi siempre será demasiado alto al moverlo a un x86 más modesto. Abre esta página desde una conexión a la máquina de producción (puerto reenviado por SSH, Cloud Run con un shell de navegador) y usa ese resultado como referencia.

📚 Datos curiosos

El número que ves en $2b$NN$ no es la cantidad de rondas en sí — es el log₂ de las rondas. Coste 12 significa 4.096 rondas, coste 13 significa 8.192, y coste 31 (el máximo teórico) sería 2.147.483.648 rondas. Esa codificación logarítmica es la razón de que la especificación solo necesite dos caracteres para el factor de coste y aun así te dé un rango de mil veces.

Los prefijos 2a, 2b, 2x, 2y que aparecen en hashes antiguos no son algoritmos distintos sino generaciones de correcciones de bugs. $2a$ fue el OpenBSD original de 1999; $2x$ y $2y$ son marcas específicas de PHP de 2011 por un fix de Crypt_Blowfish; $2b$ es el prefijo moderno y correcto que deberías generar hoy. La mayoría de validadores aceptan los cuatro por compatibilidad, pero los hashes nuevos — incluido el prefijo que esta herramienta produce — usan $2b$.