bcrypt: sal aleatoria vs sal computada

No desea utilizar una sal fija para un usuario dado, ya que podría dar lugar a la reutilización de la sal, lo que es malo (ese es el pecado capital de las sales, ya que no se debe reutilizar la idea de las sales; no tienen otra función). La reutilización de la sal puede ocurrir, prácticamente, por las dos razones siguientes:

• Si un usuario cambia su contraseña, la nueva contraseña usará la misma sal que la anterior. Eso es malo, porque las contraseñas antiguas siguen siendo valiosas (ya que los usuarios reutilizan las contraseñas, la contraseña antigua puede ser la contraseña que el usuario establecerá el próximo mes; también puede ser la contraseña para el mismo usuario en otro sitio), y la reutilización permitirá el atacante atacará tanto la contraseña antigua como la nueva por el costo de una fuerza bruta.

• Si la sal se deriva del nombre de usuario, entonces otra instancia del software del servidor, en un servidor distinto, puede terminar con las mismas sales, porque "Administrador" tiende a siempre ser llamado "Administrador". Los atacantes podrían calcular previamente una tabla grande (por ejemplo, una tabla de arco iris) para "Administrador", aplicable a muchos sitios (lo que haría que la construcción de mesas valga la pena).

Normalmente lo resumo diciendo que las sales deben ser únicas timewise (sin reutilización de un valor de sal antiguo) y a nivel mundial (sin reutilización de sales en ninguna parte, incluso en un servidor distinto). Tal singularidad es difícil de obtener, pero, sin embargo, existe una forma bastante simple, que es generar sales suficientemente grandes (por ejemplo, sales de 128 bits, como se usa en bcrypt) al azar.

Resumen: no generar sales de bcrypt al azar no sería más seguro; en el mejor de los casos, esto sería igualmente seguro, pero, probablemente, menos seguro

El motivo de una sal es, para prevenir ataques con tablas de arco iris precalculadas. El atacante tendría que construir una tabla de arco iris para cada contraseña, y eso no tiene sentido (es más fácil forzar la fuerza bruta hasta que encuentre una coincidencia). Así que el trabajo de la sal está hecho, incluso cuando es un texto plano visible en el valor hash.

Si desea agregar un secreto al cálculo, puede agregar un pimiento adicional. A diferencia de la sal, el pimiento no se almacenará en la base de datos. Esto ayudará contra ataques de diccionario, siempre que el atacante solo tenga acceso a sus datos (por ejemplo, inyección de SQL) pero no a su código.

No mezclaría sal y pimienta, porque tienen un propósito diferente. Y para responder a su pregunta, use una sal al azar y agregue un pimiento si desea agregar algo oculto.

La sal en bcrypt es de 128 bits de largo y se genera aleatoriamente, por lo que necesitaría 2 ^ 127 usuarios antes de que existiera una probabilidad del 50% de una colisión. Pongámoslo en perspectiva: cada persona en la Tierra podría hacer que un usuario cuente con cada átomo en su cuerpo, y todavía estaríamos alrededor de 1/3 del camino.

Usa la sal aleatoria. Las soluciones que incluyen sales computadas introducen algunos problemas sutiles que en última instancia pueden llevar a la diferencia entre una molestia y una catástrofe.