¿Necesita usar la misma cantidad de rondas para todas las personas con bcrypt?

El ajuste del factor de costo para BCrypt es principalmente un problema para las aplicaciones del lado del servidor. Si el factor de costo es demasiado alto, el servidor puede estar muy ocupado solo con el cálculo de hashes, cuando varias personas intentan iniciar sesión al mismo tiempo. Es por eso que intentamos encontrar un número adecuado de rondas para este servidor.

Si está haciendo el cálculo del lado del cliente, cada cliente tiene suficiente poder de CPU por sí solo para calcular incluso un gran número de rondas, la potencia aumenta con el número de clientes. Sin embargo, las aplicaciones web deberían calcular el lado del servidor hash.

Si echas un vistazo a esta implementación en PHP , verás que el número de rondas se almacena en una base de datos, lo que significa que es posible cambiar el número de rondas si es necesario.

Entonces, siempre que almacene el número de rondas en algún lugar, no necesita tener el mismo número de rondas para cada usuario.

No hay necesidad de tener el mismo número de rondas en todas partes. Cuando vuelva a marcar otra vez una contraseña determinada (p. Ej., Cuando se verifica una contraseña), debe usar el mismo número de rondas que antes (de lo contrario, no obtendrá el mismo valor), por lo que si El número no está codificado, entonces debe almacenarse junto con el valor de sal y hash. Pero la implementación habitual de bcrypt hace precisamente eso: la salida es una cadena que codifica la salida real de 192 bits, pero también el conteo de sal y iteración.

De hecho, en la mayoría de los casos donde el hash de contraseña se produce en el lado de cliente , la sal todavía se almacena en el servidor, por lo que debe organizar el envío de la sal como un paso previo; puede enviar el recuento de iteraciones en el mismo mensaje.

Tenga en cuenta, sin embargo, que la seguridad adicional contra la fuerza bruta es directamente proporcional a este recuento de iteraciones, por lo que los casos en que permita que el recuento de iteraciones sea bajo serán comparativamente más débiles. Este recuento es una compensación entre la seguridad y la conveniencia del usuario: cuanto mayor es el recuento, mejor es la seguridad, pero también cuanto más tiempo espera el usuario humano.