¿Un factor de trabajo aleatorio es un aumento o una disminución de la seguridad?

Les voy a dar dos respuestas, ninguna de las cuales es información, teóricamente correcta, ninguna de las cuales debe ilustrar por qué no molestarnos.

1. Entropía.
   Básicamente, su esquema agrega un elemento de aleatoriedad: entre 5 y 15 ciclos de hash. Entonces, cualquier número aleatorio X tal que 5 <= X <= 15 ... en otras palabras, X tiene 11 posibles valores aleatorios ... lo que le da un poco más de 3.5 bits de entropía.
   Incluso si lo llamamos 4 bits, esto realmente no es una mejora sustancial, definitivamente no es suficiente para dañar UX por ello.
   Ergo, deja a los perros hash mentir.

2. Refinamiento del ataque.
   En su esquema, el atacante es consciente de su esquema, pero simplemente no sabe cuántas veces debe realizar el ciclo del hash. En otras palabras, si intentara atacar con fuerza tus hashes, primero tendría que hacerlo 5 veces, luego 6 veces, luego tal vez 7 veces ... hasta que en el peor de los casos tiene que hacerlo 15 veces.

   Entonces? Apuntará 15 veces al hash y verificará si puede detenerse antes.

   ¿Qué acabas de hacer?
   Le diste al atacante una salida fácil , si el número de ciclos era algo menor que el máximo. Entonces, ¿por qué no darles a todos lo máximo y evitar el atajo?

Una respuesta más correcta de la teoría de la información podría ser apuntar al principio de Kerckhoffs , que básicamente afirma que el único El secreto en un sistema criptográfico debería ser la clave (o, en este caso, la contraseña). No es la elección del algoritmo, los detalles de la implementación, el número de rondas, etc., ninguno de estos debe ser considerado como secreto. Pero creo que eso es ser pedante aquí.

Y aquí hay otros puntos para pensar:

No hagas tu propio rollo.
Hay una razón por la que todos los criptógrafos son un grupo de snobs, y no es su marca especial de café.
Realmente, no intente crear su propio algoritmo, protocolo, esquema de contraseña o procedimientos de administración de claves. No lo mejorarás, y lo más probable es que lo empeoren.

Por otro lado, use lo que ya está bien revisado y considerado seguro por el mejor de los que saben. Bcrypt (y es ilk) es bastante fuerte. ¿Lo quieres más fuerte? Utilice un factor de trabajo más grande. Para eso está ahí.

el hashing de contraseñas es una compensación: usted hace que la función sea más lenta (mediante el uso de muchas iteraciones), lo que hace que los ataques y el uso normal sean más caros. Aceptas gastar más CPU en la tarea de verificar una contraseña porque sabes que también hará que el atacante gaste más CPU en la tarea de descifrar una contraseña. Una función de hashing de contraseñas decente ofrece un parámetro de "costo" que le permite configurar la lentitud de la función al mejor nivel, es decir, el más caro que puede tolerar, para sus recursos disponibles y su carga promedio.

Si hace el hash X veces, entonces el uso de X será más lento, tanto para usted como para el atacante. En la práctica, esto significa que debe reducir el número de iteraciones de la función en un factor de X , para mantener el cálculo dentro de su propio presupuesto de hardware, y esto anula exactamente cualquier ganancia de seguridad. Por lo tanto, desde ese punto de vista, su mecanismo propuesto es simplemente neutral a la seguridad (excepto que aumenta la complejidad de la implementación, que es, en igualdad de condiciones, algo malo).

Todavía hay un punto interesante a considerar, que es la aleatoriedad de X . Supongamos que genera X al azar, entre 5 y 15. En promedio, X será igual a 10; al validar una contraseña (correcta), deberá calcular la función de hashing aproximadamente 10 veces (en promedio). Sin embargo, para decidir que una contraseña es incorrecta, debes ir al 15.

Allí podríamos decir: hey, eso es bueno! El defensor (su servidor), en su uso normal, valida las contraseñas en su mayoría correctas (los usuarios tienden a escribir sus contraseñas correctamente (*)), mientras que el atacante, en su ataque de diccionario, intentará contraseñas incorrectas la mayor parte del tiempo. Así que el atacante gastará 1.5 veces más CPU en cada intento de contraseña que el defensor. ¡Acabamos de ganar un factor de 1.5x sobre el atacante! ¿No está hinchado?

No es así. El atacante es consciente de su mecanismo "aleatorio X " y organizará su ataque en consecuencia. Es decir, hará un hash de las palabras en su diccionario con 5 invocaciones de hashing, registrando los valores de hash (en la RAM, aquí solo estamos hablando de millones de valores de hash, o tal vez un par de billones, nada de extremo). Si uno de los valores de hash se ajusta, está bien, el atacante ha ganado. De lo contrario, calculará una invocación de hash adicional sobre cada valor registrado e intentará nuevamente. Y así sucesivamente.

De esa manera, el atacante también logrará el mismo tipo de eficiencia que el defensor: él también descifrará una contraseña con un costo (en promedio) 10 veces el costo de invocar la función hash. Por lo tanto, nuevamente, la ventaja de seguridad del X aleatorio se anula.

^{(*) Esta es una noción bastante optimista.}

Resumen: el factor X adicional, aleatorio o no, no aumenta la seguridad. Implementado correctamente, tampoco debería disminuirlo mucho, pero como hace que el código sea más complejo y también hace que la carga sea menos predecible, solo puedo recomendar ese mecanismo adicional.