bcrypt, el coste y el límite de 72 bytes

En bcrypt el parámetro de coste no es el número de vueltas, es el exponente: el trabajo es dos elevado al coste. Subir el coste en una unidad duplica el esfuerzo de cada verificación, tanto el del servidor como el de quien pruebe candidatos por fuerza bruta. Por eso un coste bajo es tan dañino: la diferencia entre dos valores no es lineal. La guía de OWASP pide que el coste sea el mayor que el servidor de verificación soporte con comodidad, con un mínimo de 10, y que se revise con los años.

Consulta SELECT * FROM tiempos y observa cómo crece el tiempo de una verificación al subir el coste.

Como el coste es un exponente, comparar dos servicios exige calcular: la diferencia entre costes es el exponente de la razón de trabajo. Un servicio con un coste tres unidades menor que otro hace ocho veces menos trabajo por contraseña, no tres. Esa es la cifra que va en un informe cuando se dice «este servicio está por debajo».

Lee SELECT * FROM config_bcrypt y compara el servicio con el coste más alto con el que tiene el coste más bajo.

Con la referencia de OWASP delante, un coste inferior a 10 es un hallazgo directo, y más si el servicio se creó hace poco. Pero el informe no dice solo «coste bajo»: dice qué servicio, qué valor tiene, qué referencia incumple y qué se propone. La tabla de tiempos ayuda a proponer: sube el coste mientras la verificación siga siendo asumible para el inicio de sesión.

Identifica en la configuración el servicio que no llega al mínimo.

bcrypt solo procesa los primeros 72 bytes de la contraseña; lo que venga después se ignora en silencio. Con una frase de paso larga, el usuario cree que protege toda la frase y en realidad solo cuenta el principio. Se detecta con una prueba autorizada sobre una cuenta de prueba: se cambia un único byte en una posición concreta y se mira si la entrada sigue funcionando. Si sigue funcionando, ese byte no cuenta. La configuración de app-conductores deja escribir hasta 200 bytes sin ningún tratamiento previo, y eso es lo que la prueba comprueba.

Lee SELECT * FROM pruebas_truncado: una de las dos cuentas siguió entrando después del cambio.

Hay dos arreglos válidos. El primero, limitar la longitud de la contraseña a lo que bcrypt procesa y avisar al usuario. El segundo, hacer un prehash: reducir la contraseña con una función de hash y codificar el resultado en base64 antes de pasarlo a bcrypt, para que el valor sea de longitud fija y no contenga bytes nulos que corten la lectura. OWASP recomienda además que, si se hace prehash, se combine con una pimienta mediante HMAC. Lo que no es un arreglo es subir el coste o ampliar el formulario: el límite es de la función.

Mira la columna de prehash de config_bcrypt y contrasta cada servicio con lo que de verdad hace.