Implicaciones de seguridad de almacenar el hash de contraseña a lo largo de una clave AES cifrada

Solo para asegurarte de que lo tengo, estás almacenando:

• la contraseña con hash, teóricamente la contraseña no se puede recuperar, ya que el hash es de una manera.

• la sal: solo la mitad de la ecuación para la clave de cifrado, ya que también necesita la contraseña en claro , ¿verdad?

• la clave AES cifrada

Entonces ... la clave AES es la verdadera recompensa, presumiblemente, porque se usa para la comunicación o el almacenamiento cifrados.

Cuando quieras que el servidor use la clave, supongo que el proceso es el siguiente:

• el usuario le da al sistema su contraseña
• el sistema verifica la contraseña, la revisa, y está bien.
• el sistema toma la contraseña (¡no el hash!) y el salt y calcula la clave de cifrado
• el sistema toma la clave de cifrado y descifra la clave AES

Luego, el sistema maneja la clave AES de manera adecuada, hace lo que tiene que hacer y borra cualquier copia de la clave AES de la memoria para que no se encuentre en ningún sitio.

Tal como está, no veo una debilidad en eso, pero has reducido todo a la fuerza de la contraseña. Si un atacante debe obtener su almacén de datos, lo único que necesita pero no tiene es la contraseña. Si un usuario tiene una contraseña fácil de adivinar, el atacante obtendrá la clave AES del usuario.

Creo que si estuviera analizando este sistema, no me preocuparía demasiado por eso, en cambio, empezaría a indagar cómo se comunican las contraseñas de los usuarios y cómo se maneja la clave AES después de descifrarla. Estas son débiles. puntos, también, y puede ser más fácil de piratear que un almacén de datos de back-end de hashes, sales y claves cifradas.

Si un atacante quiere romper tu sistema, intentará adivinar la contraseña. Esto significa probar contraseñas potenciales hasta que una "coincida" (eso es lo que se denomina ataque del diccionario ). Coincide con qué? Hay dos formas en que un atacante puede ver si la contraseña es correcta:

1. verificando el hash almacenado;
2. aplicando la derivación de contraseña PKCS # 5 (PBKDF1 o PBKDF2, PKCS # 5 describe ambas), luego desencripta la clave AES, luego usa la clave obtenida para intentar descifrar lo que esté cifrado con that clave, y ver si el resultado tiene sentido.

El atacante empleará la forma más fácil para él. Las funciones PBKDF * incluyen algunas características que hacen que los ataques de diccionario sean más difíciles, a saber, la sal y un número configurable de iteraciones internas. Las iteraciones hacen que cada prueba de contraseña sea costosa. La sal evita que el atacante optimice las cosas con una gran tabla de hashes precomputados (por ejemplo, una "tabla de arco iris"). PBKDF2 se considera bastante bueno en eso (aunque bcrypt es posiblemente mejor ). Si su hash de verificación de contraseña no incluye las mismas características, entonces el hash es una debilidad que usará un atacante.

En pocas palabras, su seguridad será la del debilitamiento de su hash de verificación de contraseña y la derivación de la clave PKCS # 5.

Un mejor esquema sería el siguiente:

• A partir de la contraseña del usuario, deriva una clave K utilizando una función de derivación de clave adecuada, por ejemplo. PBKDF2 o bcrypt. Esto utiliza una sal S .
• Cifras tu "clave AES" simétricamente con K , dando un valor B .
• Almacena h (K) , S y B para cada usuario (donde h es un dispositivo seguro Función hash: sugiero SHA-256).

Para verificar una contraseña, vuelva a ejecutar la función de derivación de claves, utilizando la sal almacenada S , y haga un hash del resultado para ver si coincide con la h (K) almacenada. . Si desea descifrar B , simplemente use la K reconstruida. De esta manera, está seguro de que la derivación de clave utilizada para el cifrado y el hash de verificación de contraseña son igualmente resistentes a los ataques de diccionario.

No creo que quieras guardar el hash junto a la clave AES. Si alguien tuviera acceso a la clave AES, el hash y el salt encriptados sin formato, podría forzar la fuerza de la contraseña solo con el hash. Dado que el consumo de energía computacional de hoy en día, el hecho de forzar todas las contraseñas alfanuméricas de solo 6 letras lleva 2 segundos usando la GPU lista para usar. Algoritmos como MD5, SHA1 e incluso SHA256 pueden forzarse con fuerza bruta con una pequeña cantidad de la potencia computacional de hoy.

enlace

enlace

enlace

enlace

Entonces, digamos que no guardó la contraseña como un hash junto a ella. El atacante aún podría aplicar fuerza bruta a la clave AES encriptada, pero si el cálculo utilizado para calcular la encriptación es significativamente más alto que el hashing, es posible que no sea posible la fuerza bruta. Los algoritmos de hash como MD5 y SHA1 están diseñados para la velocidad. Así que realmente se reduce a qué algoritmo es más alto en complejidad computacional en cuanto a qué tan bien este esquema le brinda protección.

Sin embargo, ambos algoritmos probablemente caerán en la contraseña < 8 caracteres de longitud. Una contraseña de 7, con combinación de cascos, todos los símbolos solo toma 7 horas en una GPU para ciertos algoritmos. No es mucho esperar si esta información es lo suficientemente importante.

BTW no es útil porque está almacenado a la vista, así que debes asumir que tu atacante puede saberlo. Lo único que hace la salazón es prevenir los ataques a la mesa del arco iris, que son bastante inútiles ahora que solo podemos hacerles fuerza bruta.