¿Alguna razón para retardar las contraseñas de hash generadas al azar en nuestro sitio?

Bien, entonces el sitio genera una contraseña aleatoria para cada usuario en el momento del registro. Una pregunta importante es si un usuario puede configurar manualmente su contraseña más tarde, o si se les obliga a usar una contraseña aleatoria generada por el sitio. Veamos los dos casos por separado.

Contraseñas aleatorias

Por lo que puedo decir, este es el escenario que está describiendo en la pregunta. Desafortunadamente, tu desarrollador es (en su mayoría) correcto . Al menos sobre la iteración única de hash vs un hash lento grande. Su pregunta tiene el sabor de aplicar ciegamente "mejores prácticas" sin tener en cuenta para qué estaban destinadas esas prácticas. Para un ejemplo brillante de esto, aquí está una buena lectura:

El chico que inventó esas molestas reglas de contraseña ahora lamenta perder tu tiempo

Sugerencia

Cambie de MD5 a SHA256 , probablemente agregue una sal por usuario y tal vez considere usar contraseñas de 32 caracteres. Pero agregar una función de hashing lenta y grande aumentará la carga de su servidor por poco o nada de seguridad (al menos, al menos cualquier otro error en su implementación).

Entender el hash como una mitigación de fuerza bruta

La cantidad de trabajo que debe realizar un atacante de fuerza bruta que ha robado su base de datos para descifrar los hashes de contraseña es aproximadamente:

entropy_of_password * number_of_hash_iterations * slowness_of_hash_function

donde entropy_of_password es el número de posibilidades o "capacidad de detección" de la contraseña. Mientras esta "fórmula" sea más alta que 128 bits de entropía (o factor de trabajo equivalente o número de instrucciones hash para ejecutar), entonces está bien. Para las contraseñas elegidas por el usuario, el entropy_of_password es abismalmente bajo, por lo que necesita muchas iteraciones (como 100.000) de una función hash muy lenta (como PBKDF2 o scrypt ) para obtener el factor de trabajo.

Por "dígitos hexadecimales de 20 dígitos" Supongo que quiere decir que hay 16 ²⁰ = 2 ⁸⁰ posibles contraseñas, que es inferior a la "mejor práctica" 2 < sup> 128 , pero a menos que seas un gobierno o un banco, probablemente tengas suficiente seguridad de fuerza bruta solo a partir de la entropía de la contraseña.

tampoco tienen ningún propósito aquí porque el cálculo previo de todos los hash es como 2 ⁸⁰ * 32 bits / hash, que es aproximadamente 1 ZB (o 5000 x la capacidad de todos los discos duros del planeta combinados ). Las tablas Rainbow ayudan un poco, pero francamente, cualquier atacante capaz de hacer eso merece ser parte de todos nosotros.

Aún desea cifrar la contraseña para evitar que el atacante elimine el texto sin formato de forma gratuita, pero una iteración de hash es suficiente. Sin embargo, cambie de MD5 a SHA256 y quizás considere usar contraseñas de 32 caracteres.

contraseñas del cerebro humano

Los comentaristas de este hilo parecen obsesionados con la idea de que, a pesar de su declaración de que el sitio genera contraseñas, los usuarios pueden elegir sus propias contraseñas.

Tan pronto como el usuario tenga la posibilidad de cambiar la contraseña, la única iteración de hash no es una opción para almacenar la contraseña de baja entropía. En este caso, tiene razón en que necesita hacer todas las mejores prácticas para el almacenamiento de contraseñas.

Salado

De cualquier manera (contraseñas elegidas por el usuario o aleatorias) probablemente querrás un salt por usuario.

Si es elegido por el usuario , las sales forman parte de las mejores prácticas. 'nuff dijo.

Si es aleatorio , @GordonDavisson señala un ataque realmente bueno en los comentarios [1] , [2] basado en la observación de que una búsqueda de db es esencialmente gratis en comparación a una computación hash. Calcular un hash y compararlo con los hashes de todos los usuarios es esencialmente el mismo costo que compararlo con el hash de un usuario específico . Mientras esté contento de ingresar a la cuenta de cualquier (en lugar de intentar descifrar una cuenta de específica ), mientras más usuarios haya en el sistema, más eficiente será el ataque.

Por ejemplo, supongamos que roba la base de datos hash sin sal de un sistema con un millón de cuentas (aproximadamente 2 ²⁰ ). Con 2 ²⁰ cuentas, estadísticamente espera obtener un impacto en las primeras 2 ⁶⁰ suposiciones. Todavía estás haciendo O (2 ⁸⁰ ) adivina , pero O (2 ⁶⁰ ) hashes * O (2 ²⁰ ) búsquedas de base de datos ~ = hashes de O (2 ⁶⁰ ).

Las sales por usuario son la única forma de evitar que ataque a todos los usuarios por el costo de atacar a un usuario .

Complementando la respuesta de Mike Ounsworth , tu desarrollador probablemente esté en lo correcto, siempre que estén generando sus números aleatorios. correctamente.

Si coloca su PRNG que genera estas contraseñas de manera incorrecta, un atacante puede inferir el estado de su PRNG para predecir futuras contraseñas. Por ejemplo, en un caso muy patológico en el que utiliza un Mersenne Twister con un estado interno que no se actualiza entre sesiones, el siguiente ataque es viable:

1. Solicito un gran número de cuentas en secuencia
2. Usted genera una cantidad correspondientemente grande de bytes desde su PRNG y me los envía a todos
3. Utilizo esos bytes para inferir el estado interno de su PRNG en el momento en que generé mis contraseñas
4. De esto, deduzco el estado interno de su PRNG en el momento en que generó las contraseñas de cada usuario subsiguiente. Cada contraseña futura que genere tu PRNG puede ser predicha por mí. Además, el MT puede ejecutarse hacia atrás para generar todas sus salidas anteriores desde un punto conocido en el tiempo
5. Ahora he computado todas las contraseñas en uso por su sistema sin tener acceso a su base de datos

Asegúrese de utilizar una fuente de aleatoriedad criptográficamente segura. El PRNG incorporado de su idioma puede no serlo.

Además, ¿cómo van a recordar realmente sus usuarios estas contraseñas? Generar algo largo e impredecible solo hará que los usuarios ahorren password.txt en sus escritorios. Si la contraseña debe estar escondida en un archivo de configuración en algún lugar, entonces es probable que no tenga un problema real, pero si se supone que algo está en la cabeza de un usuario, está sobreestimando enormemente las capacidades de sus usuarios. haciendo que inventen sus propios fallos de seguridad.

Como han dicho otros, revertir el MD5 de un número aleatorio de 80 bits es un problema difícil, por lo que si alguien obtiene su tabla de hashes, probablemente no podrán acceder a las cuentas de usuario.

Sin embargo, es posible que desee considerar dónde almacenan los usuarios esos números aleatorios de 80 bits. Probablemente no va a estar en sus cabezas. En el mejor de los casos, se encuentra en una aplicación de repositorio de contraseñas o llaveros razonablemente segura. En el peor de los casos, tendrán un archivo con PASSWORDS_FOR_YER_APP.TXT en su directorio de inicio.

El MD5 como usted dice es inseguro, principalmente debido a los descubrimientos en 2013 que le permiten ser atacado por colisión en 2 ^ 18 veces (aparentemente menos de un segundo en las máquinas modernas).

Independientemente de si no se va a utilizar la contraseña en otros sitios, su sitio sigue siendo inseguro. El hecho de que sea aleatorio y, por lo tanto, no aparezca en las tablas de búsqueda de ningún tipo, no significa que no se pueda romper por colisión. Eso significa que si alguien obtiene el hash, puede determinar fácilmente algo que funcionará como una contraseña, asumiendo que usted verifique los hashes.

Como han dicho otros, use un método mejor: la familia SHA es buena, pero muchos prefieren SCrypt y BCrypt para las contraseñas, y si las contraseñas generadas al azar con las que está tratando probablemente no necesitarán sal.