¿Cómo calcular la cantidad total de combinaciones de contraseñas posibles que tienen valores de sal?

La sal se almacena en forma simple, junto con el hash, por lo que no es necesario probar múltiples combinaciones de sal cuando se conoce la sal correcta. Esto hará que tus cálculos sean simples.

Si no hay sal, uno podría descifrar todas las contraseñas en un trabajo de fuerza bruta.

Pero si cada uno de los 4 usuarios tiene una sal diferente, entonces tomará 4 trabajos separados de fuerza bruta.

Entonces, 296.653 años para una sola sal × 4 sales únicas = 1.186.612 años para descifrar las contraseñas de todos los usuarios.

Siendo nervioso: para b. Si usa años como unidad de tiempo, asegúrese de usar 365.25 días / año en lugar de 365, debe tener en cuenta el año bisiesto.

c. es complicado La pregunta inicial le pide que asuma que el sistema no está usando ningún valor de sal. En el prefacio de la parte c, mencionan que cada usuario tiene una sal única. No dejes que eso te desanime. ¿El texto anterior a esta pregunta menciona qué algoritmo de hash se utilizó para cifrar las contraseñas inicialmente? Si no se menciona cuánto tiempo se usaría al incluir una sal definida, y cada sal es única por el hash de contraseña, el cálculo es sencillo.

En este ejemplo, el software tardaría 296k años en descifrar una contraseña sin sal, y no hay una penalización de tiempo para la distribución de sal, luego se supone que cada sal única requeriría la misma cantidad de tiempo por contraseña. Tampoco hay ninguna especificación de que el cracker de contraseñas sea multiproceso. El cálculo sería:

• (x (contraseñas) * tasa (tiempo / contraseña)) / n (hilos) = tiempo
• (4 contraseñas * 296K años) / 1 hilo = 1.185 M años

También ... si las sales son las mismas por contraseña, una respuesta correcta sería "menos de 1.185M años", de lo contrario, su respuesta sería solo "1.185 M años".

Lo que hacen las sales únicas por usuario es hacer que los cálculos realizados para atacar la contraseña de un usuario sean inútiles para atacar a cualquier otro usuario. Alternativamente, si no hay sales, entonces, para cada contraseña que intente el atacante, pueden probar esa contraseña con los hashes de los cuatro usuarios. Si hay sales únicas, el atacante debe realizar un ataque de fuerza bruta por separado para cada entrada de contraseña.

Eso debería ser suficiente de una pista.

Debo agregar que me preocupa la calidad de los materiales de enseñanza que está utilizando. Acaba de citar un pequeño fragmento de código y, sin embargo, veo varias banderas:

1. Habla de "cifrar" las contraseñas en lugar de marcarlas .
2. 6.4 millones de "encriptaciones" por segundo no es realmente tan rápido como podría sonar. Las GPU pueden calcular órdenes de magnitud más hashes por segundo. No afecta la respuesta del problema, pero mejorar su realismo estaría bien.
3. El número de mayor interés no es la cantidad de tiempo para probar todas las contraseñas, sino el tiempo promedio hasta que el atacante tenga éxito.
4. El tiempo estimado supone que los usuarios eligen sus contraseñas de manera uniforme y aleatoria, que no es la forma en que la mayoría de los usuarios de la vida real lo hacen.

Para expandirse en el tercer punto, el cracker tendría que ser extremadamente desafortunado para que su fuerza bruta última sea la correcta. Ese sería el peor caso; en promedio, solo necesitan probar la mitad de las posibles contraseñas para tener éxito.

(Y si estamos hablando de cuatro usuarios con contraseñas no guardadas , y asumimos que el objetivo es la fuerza bruta de una contraseña, que más trimestres el tiempo esperado hasta el éxito.)

En el punto # 4, si el atacante puede adivinar contraseñas más probables antes que las improbables, eso reduce el tiempo esperado hasta el éxito. En la vida real, el descifrado de contraseñas usa una variedad de técnicas para intentar esto (por ejemplo, diccionarios de contraseñas comunes), y esas técnicas son muy exitosas.

Sinceramente, espero que las contraseñas estén (unidireccionales, preferiblemente a través de una función lenta) sin cifrar (no de forma reversible) cifrada . Hay muy pocas situaciones en las que el cifrado de las contraseñas de inicio de sesión es una buena idea (principalmente porque, si lo hace, un atacante que logró robar sus verificadores de contraseña probablemente también logró robar la clave de cifrado y les tomará milisegundos descifrar los verificadores y recuperar las contraseñas).

Suponiendo que están en hash, no encriptados, agregar un salt no hace que tome más tiempo por contraseña , porque el salt solo tiene un prefijo (o se adjunta) a cada valor de contraseña que se encuentra Antes de que lo hash y compruebe el hash. Sin embargo, significa que cada contraseña debe ser forzada de forma independiente; incluso si compites todo el espacio de búsqueda para la contraseña 1, eso no te ahorrará tiempo con la contraseña 2 porque la sal es diferente. No voy a darte la respuesta aquí, pero sabes cuánto tiempo tomará la contraseña de fuerza bruta una de forma independiente ...