¿Cómo debo elegir un factor de dificultad para la función de hashing de mi contraseña?

Desafortunadamente, la amplia variedad de hardware impide la creación de tablas como la que usted desea, a menos que primero realice un estudio de todas las arquitecturas de hardware existentes y las mejores implementaciones de bcrypt / scrypt / PBKDF2 para esa arquitectura. Incluso la tabla en el artículo de scrypt no es lo que quieres: no te dice cuánto costaría para un atacante; indica cuánto costaría para un atacante con el hardware y el software que el diseñador scrypt pensó al escribir el artículo .

Estas estimaciones no se escalan bien, por cierto. Si fuera un atacante que enfrentara un costo de ataque estimado en 10 billones de dólares con el hardware disponible, primero invertiría mil millones de dólares en la construcción de un sistema personalizado basado en ASIC que sería más rápido para ese trabajo. Una PC es buena para hacer accesos pseudoaleatorios a la RAM, pero no es el mejor hardware para eso, aunque solo sea porque hay muchos otros componentes en una PC, que son inútiles. para un ataque.

Al menos, para PBKDF2, dado que los cálculos se asignan a la función de hash subyacente sin problemas de acceso a la memoria, puede usar los puntos de referencia de la función de hash existente para obtener una idea (por ejemplo, estas ).

Dicho esto, no todo está perdido. No obtendrás estimaciones precisas de los costos de ataque, pero eso no significa que todo lo que puedes hacer es lamentarte, encogerte y morir. Un primer método pragmático es configurar el recuento de iteraciones tan alto como pueda : configúrelo en el valor más alto que no haga que el proceso de inicio de sesión normal sea intolerablemente lento. De esa manera, no sabrá si su seguridad es buena , pero será lo mejor que pueda . Que es un consuelo.

El resto del trabajo estará del lado de los usuarios. Después de todo, el factor de dificultad en el hash de la contraseña está ahí para contrarrestar la ley de Moore. Sin embargo, en el mejor de los casos, es una coincidencia entre la entropía de contraseña y la paciencia del atacante :

• La ventaja del atacante es que es más rico, puede comprar hardware dedicado y es paciente : puede gastar una hora, tal vez un día en descifrar una contraseña de alto valor; mientras que el usuario no tolerará esperar más de un segundo al iniciar sesión.
• La ventaja del defensor es la entropía de contraseña .

Contabilizando un factor de eficiencia de 1000 para el atacante (hardware dedicado, más dólares arrojados a él) y un factor de paciencia de 86400 (el atacante desea tener éxito en un día, el usuario no esperará más de un segundo), luego, la entropía de la contraseña debe exceder los 86 millones (es decir, un poco más de 26 bits) si el defensor debe ganar el juego. Para aumentar la contraseña de la entropía, solo hay una manera: educar, educar y educar nuevamente. No intente hacer cumplir las "reglas de contraseña", se oponen a los usuarios en lugar de crear contraseñas seguras. En su lugar, proporcione un botón generador de contraseña no obligatorio , que produce contraseñas con, por ejemplo, 40 bits de entropía, y explique a los usuarios que usar el botón sería una muy buena idea.

Al utilizar su hardware de destino, seleccionaría un costo que haga que el algoritmo tome aproximadamente 1/10 de segundo. Implementar un retraso después de los intentos fallidos de inicio de sesión. No será rentable forzar con fuerza cualquier contraseña que no haya sido mal escogida (por ejemplo, el nombre de usuario, el nombre del sitio, la "contraseña"). El valor real que elija dependerá de su hardware de destino.

1. la velocidad del algoritmo no importa si las contraseñas son débiles.
2. si la contraseña está en un diccionario, estás casi jodido instantáneamente
3. si la contraseña es generada por una regla que se incluye con JtR o Hashcat, un poco más tarde se equivocó;)

Aparte de eso, ¿cuántos usuarios / contraseñas almacena? Si solo está protegiendo una cuenta (piense en un servidor con solo la cuenta raíz en ella), entonces el uso de sal es discutible.

¿Con qué frecuencia se ve obligado a cambiar las contraseñas? Si la dificultad de la contraseña forzará al atacante a formar un conjunto completo de caracteres, una contraseña de fuerza bruta larga, entonces puede hacer una aproximación decente: NumberOfCombos / CrackSpeed = TimeToCrack

Por lo tanto, si tiene un ASCII imprimible completamente al azar de 6 caracteres (95 símbolos) que puede descifrar a 100 por segundo, entonces tiene 95 ^ 6/100 = 233 años para romper todo el espacio de teclas.

Sin embargo, si está usando algo que es rápido (mi GPU agrieta una sola ronda, MD5 sin sal a 8 mil millones / s), y le lanza un hardware decente, entonces puede romper todo el espacio de teclas de 6 caracteres. en unos 90 segundos. Ir a la longitud 7 en el mismo juego de caracteres extiende el tiempo hasta la grieta a > 2hrs, y la duración 8 lo extiende a 9 días. Entonces, si cambias tus contraseñas cada 90 días, eso le da al atacante suficiente tiempo para descifrar y usar esa longitud 8, la contraseña del conjunto de caracteres 95.

La regla es simple: cuanto más grande sea el conjunto de caracteres y más larga sea la contraseña, el espacio de las teclas crecerá a una velocidad ridícula. El hardware y el software modernos hacen que el craqueo sea muy rápido, pero puede mitigar la amenaza con sales / algos. El verdadero asesino es cuando no forzaste al atacante en un escenario de fuerza bruta. Los diccionarios / reglas / permutaciones / ataques de combinación de múltiples palabras son extremadamente eficientes para encontrar contraseñas no aleatorias.