¿Cuál es el algoritmo recomendado para crear una clave a partir de una contraseña?

2

En mi nueva utilidad de cifrado de documentos secretos, la clave para el cifrado simétrico = el hash de un salt aleatorio y una contraseña proporcionada por el usuario.

Es necesario tener una función hash lenta para evitar la fuerza bruta en contraseñas menos que óptimas. MD5 y SHA1 han demostrado ser inmensamente rápidos, por lo que obviamente no es suficiente. Tampoco tengo grandes esperanzas para SHA256.

Una de las opciones es repetir la operación de hashing un número absurdo de veces. Debido a la gran repetición necesaria (100k mínimo ), estaba algo preocupado por los atacantes que sabrían una forma de saltar adelante con atajos, tal vez usando la tabla rho, o algún otro medio.

¿Es este enfoque de 100.000 rehash el sonido, o debo usar algún otro algoritmo para crear una clave a partir de una contraseña y sal?

Obviamente, también puedo requerir una contraseña más compleja, pero creo que un buen objetivo sería admitir la variación de 6 letras sin diccionario, incluso si necesito un segundo entero de reinicio para realizar el desbloqueo. Este es un objetivo alcanzable, y creo que es mejor permitir contraseñas más cortas si a) eso es lo que quiere el usuario yb) no tiene un impacto significativo en la seguridad.

1. Una estimación de cuánto tiempo tomaría el hash para un procesador de < 2 Ghz es de 1 milisegundo por cada 1-2 mil repeticiones (según el algoritmo). Para las contraseñas de 6 letras, que no sean de diccionario, que deben demorarse durante 1 año, necesitaríamos la generación de claves para tomar al menos 100 milisegundos .

    
pregunta George Bailey 27.02.2012 - 17:58
fuente

3 respuestas

5

Algunas de las opciones populares para esto son PBKDF2, bcrypt y scrypt. Una respuesta relacionada tiene mucha información buena. Lo esencial es que Bcrypt es mejor que PBKDF2, pero cualquiera de los dos estaría bien y seguro. scrypt se ve prometedor, pero es bastante nuevo, y en el mundo de la criptografía, a menudo utilizamos de forma predeterminada lo probado y probado, a menos que sea absolutamente necesario. Vea la respuesta a la que he vinculado para los ataques contra los cuales Scrypt es mejor que bcrypt.

    
respondido por el mikeazo 27.02.2012 - 18:13
fuente
3

Te recomiendo que uses PBKDF2. Está diseñado exactamente para este propósito: derivar una clave criptográfica de una contraseña. Puede ajustar PBKDF2 para que la derivación de la clave criptográfica tome el tiempo que desee (más = más seguro, pero demasiado largo = inconveniente). Puede almacenar la sal en el claro junto con el texto cifrado.

No creo que recomiendo usar bcrypt o scrypt. Están diseñados para las contraseñas de hash. Si bien bcrypt o scrypt ciertamente podrían constituir la base para una solución razonable, no son directamente adecuados y es posible que necesite hacer algunos ajustes ( con cuidado ), por lo que Probablemente sea más fácil usar PBKDF2 de forma segura.

No me molestaría con xor-ing bcrypt y PBKDF2. PBKDF2 está bien por sí solo; no hay necesidad de xor con cualquier otra cosa.

    
respondido por el D.W. 28.02.2012 - 22:17
fuente
2

En una nota aparte, quiero advertirle sobre los problemas de seguridad con el uso de frases de contraseña cortas para derivar claves criptográficas.

Usted menciona una hipotética "6 letras, no contraseña de diccionario". Bueno, aquí hay una nota de precaución sobre eso. La mayoría de las contraseñas de 6 letras no tienen la fuerza de una colección aleatoria de 6 letras; La mayoría de las contraseñas de 6 letras tienen una buena estructura. Y simplemente decirles a los usuarios que "no usen una palabra del diccionario" no es suficiente para cambiar eso.

También quiero advertirle sobre la posibilidad de paralelización. Usted menciona que una "contraseña de 6 letras que no está en el diccionario" debería "retrasarse durante 1 año" si la generación de claves toma al menos 100 milisegundos. Bueno, creo que lo que quieres decir es que si no hay una estructura en la contraseña, entonces romper la clave criptográfica tomará al menos 1 año de CPU. Hay una gran diferencia entre 1 año de CPU y 1 año. Alguien que obtenga 100 máquinas podría descifrar la contraseña en unos pocos días. Es un nivel de seguridad bastante bajo, en el mundo actual de botnets, EC2 y cloud computing. Y eso ya supone que sus usuarios elegirán contraseñas de 6 letras perfectamente aleatorias, una suposición que sabemos que es totalmente falsa.

Por estas razones, las contraseñas elegidas por el usuario generalmente no son una buena base para una clave criptográfica. Es probable que una fracción sustancial de las contraseñas elegidas por el usuario se puedan romper a través de ataques de fuerza bruta, incluso si utiliza PBKDF2. Por lo tanto, es posible que desee considerar seriamente qué más puede hacer, además de PBKDF2, para proteger a sus usuarios.

Una posibilidad podría ser generar una frase de contraseña sugerida al azar para el usuario (por ejemplo, cinco palabras elegidas al azar de un diccionario de 4096 palabras, o diez caracteres elegidos al azar de a-zA-Z0-9), y hacer que Fácil para el usuario utilizar su sugerencia. Otro método podría ser probar la calidad de la frase de contraseña del usuario, y si parece ser deficiente, advierta al usuario que su frase de contraseña es probablemente insegura y tal vez proporcione una alternativa recomendada (por ejemplo, use la siguiente frase de contraseña sugerida). Otro método es utilizar la criptografía de clave pública, pero automatizar el proceso para que el usuario no tenga que estar al tanto de lo que está sucediendo. Probablemente también hay muchas otras posibilidades creativas que podría considerar, dependiendo de los detalles de su dominio de aplicación específico.

    
respondido por el D.W. 28.02.2012 - 22:30
fuente

Lea otras preguntas en las etiquetas