¿Cuáles son los deméritos de un salt derivado para el almacenamiento de contraseñas?

La razón para agregar un poco de sal a una contraseña antes de incluirla, es hacer que sea mucho más difícil revertirla. Por lo tanto, un número completamente aleatorio es la mejor solución.

Tener que encontrar un número de "sal derivada" que sea lo suficientemente único como para que la mayoría de las contraseñas de los usuarios tengan un hash diferente será difícil. Al generar un número de sal suficientemente grande (16 bytes, por ejemplo) probablemente será único para todos los usuarios que alguna vez crearán una cuenta en su sistema sin mucho esfuerzo por su parte para determinar la singularidad.

Además, usar un parámetro como la dirección de correo electrónico del usuario puede ser complicado. Si desean cambiar su dirección de correo electrónico, perderá su "sal derivada" a menos que obligue al usuario a cambiar su contraseña al mismo tiempo que cambian su dirección de correo electrónico (o cualquier otro parámetro de usuario utilizado en el cálculo de su "sal derivada"). .) De cualquier manera, seguramente querrá guardar el salt en la base de datos para asegurarse de que siempre pueda comparar las contraseñas en los futuros inicios de sesión de usuarios.

No creo que una sal derivada única sea peor que una sal única aleatoria. El único propósito de un salt es confundir el descubrimiento de las contraseñas cuando se obtiene la tabla de hashes.

Para que una contraseña se descubra a partir de un hash, tiene que ser algo que se pueda adivinar en el sentido de que se encontró en una tabla de arco iris existente, o (por ejemplo) idéntica a otra contraseña en el conjunto de datos.

+--------------------------------------------------+
|    password   |               hash               |
+---------------+----------------------------------+
| freaky        | 33ca4223307e2fa4fd77c394ceb4e37b |
| freaky        | 33ca4223307e2fa4fd77c394ceb4e37b | <- identical to previous
| Freaky Friday | 852d2f614f08a63911f8944df6df40df |
| ...

En vista de eso, permítame reafirmar el propósito con un grano de precisión adicional:

El único propósito de un salt es confundir el descubrimiento de contraseñas fáciles de adivinar cuando se obtiene la tabla de hashes.

Incluso la peor sal posible apoya ese objetivo bastante bien. Digamos, para argumentar, que debía agregar sal a cada fila con los 8 bytes predecibles y bastante obvios " Salted__ " (observando, por favor, no haga esto).

En Crackstation.net hoy ni siquiera encuentro " Salted__123456 ", por lo que probablemente el atacante tendría que identificar o crear una tabla de arco iris personalizada antes de poder comenzar el ataque. Pero tenga en cuenta que las contraseñas débiles como " freaky " seguirían teniendo el mismo hash y, por lo tanto, seguirían siendo un foco inicial para que el atacante intente las "contraseñas de la X superior" o lo que sea. Y una vez que se construyó la tabla del arco iris, el ataque podría continuar durante todo el conjunto de datos.

La siguiente opción de sal más poderosa, por lo tanto, sería única por fila. Eso significaría que el atacante tendría que construir una tabla nueva de arco iris para cada contraseña. Esto significa que si el atacante solo está detrás de uno de sus usuarios, el esfuerzo es el mismo que el sal estático anterior. Pero, si el atacante quiere su mesa completa, la complejidad del tiempo de agrietamiento ha aumentado.

No creo que haga una diferencia si la sal es única y aleatoria; o simplemente único.

Imagina que eres el atacante y tienes los hashes. Sabes que vas a tener que construir una tabla de arco iris para atacar a cada fila. ¿Importa cuáles son los valores de sal? Si ve el valor de sal único en la tabla de hashes; o si sabe que la sal es el customer_id o lo que sea, no cambia la cantidad de trabajo que tiene que hacer.

Luego imagina que eres el atacante y NO tienes los hashes. ¿Qué sucede si se entera de que las contraseñas están incluidas en el ID del cliente? Supongo que esto significa que usted podría calcular previamente todas las tablas del arco iris antes de realizar un robo de hashes, pero esto no disminuye la parte difícil de su carga de trabajo, por lo que diría que es insignificante.

El punto principal de agregar sal es aumentar la entropía de la contraseña. Esto es para proteger del potencial para que cualquiera pueda crear tablas de arco iris preconstruidas de un gran conjunto de contraseñas para descifrar contraseñas.

La forma más fácil y sencilla de hacerlo es simplemente generar un número aleatorio. Puedes generar tanta entropía como quieras. Es un diseño simple que es fácil de implementar y difícil de estropear.

Elegir algunos detalles aleatorios de un usuario y usarlo como una sal derivada es a la vez más complicado y fácil de arruinar. El esquema que se te ocurrió en realidad proporciona MÁS información sobre la contraseña, lo que facilita su descifrado. La dirección de correo electrónico es conocida, la contraseña no. Pero ya que está proporcionando la suma de los valores de contraseña en el salt, ahora hay una comprobación previa fácil antes de intentar el hash. Antes de intentar hacer un hash de la contraseña (debe ser lento) Simplemente sume la contraseña (intentada) y compárela con la suma de su sal almacenada. Si no coincide, pruebe con otro. Esto puede aumentar GRATAMENTE los intentos de adivinación, ya que sumar la contraseña potencial es MUCHO más rápido que el hash.

Por supuesto, esto se puede resolver con un diseño diferente, pero el punto es que el diseño de seguridad es DIFÍCIL, y es por eso que normalmente debería ir con soluciones bien aceptadas sobre las suyas. Es mucho menos probable que caigas en trampas bien conocidas de esa manera.