¿Conseguirá la clave de cifrado derivada del hash de contraseña comprometerá la clave?

Question

¿Conseguirá la clave de cifrado derivada del hash de contraseña comprometerá la clave?

#1 de Andrey (0 votos)

0

He estado observando cómo se utiliza PBKDF para generar la clave de cifrado para AES. Una cosa que no pude entender es cómo esos sistemas operativos mantienen segura la clave de cifrado además de usar módulos de hardware.

Hasta ahora, tengo entendido que el sistema operativo, como Windows, almacena la contraseña de usuario con hash en un archivo (archivo SAM). El hash de contraseña se usa para generar la clave de cifrado para las aplicaciones que necesitan cifrar datos. Esto se hace en DPAPI y las aplicaciones pueden simplemente llamar a la API y la biblioteca del sistema extraerá automáticamente la contraseña de usuario (hash) del contexto actual y derivará una clave de ella (de una manera sencilla, tal vez más complicada que esto). Pero, ¿cómo garantiza Windows la seguridad de la clave de cifrado, incluso si la clave solo se genera sobre la marcha, siempre que el atacante obtenga el hash, no comprometería la clave de cifrado de alguna manera, ya que pueden aplicar el mismo PBKDF2? si de alguna manera pueden probar aquellos con posibles casos).

Si un atacante toma el archivo de contraseña de Windows y extrae el hash (no debería ser demasiado difícil), ¿puede aplicar PBKDF2 (o cualquier posible función de derivación) encima para obtener la clave de cifrado? ? . ¿Es algún valor de sal codificado cuando el PBKDF2 se aplica al hash en la fuente de Windows?

Gracias

cryptography aes pbkdf2

pregunta grumpynerd 03.08.2014 - 09:27

fuente

1 respuesta

Lea otras preguntas en las etiquetas cryptography aes pbkdf2

Hackeando máquinas usando paquetes de internet [cerrado] Integración de la aplicación de pago - Cifrado o HMAC

score 0 · Accepted Answer

Si la clave de cifrado se puede derivar utilizando solo los datos que persisten en la base de datos del usuario (como el nombre de usuario y el hash de la contraseña, por ejemplo) eso constituiría un defecto de diseño importante por las razones que describió anteriormente: el secreto original (contraseña del usuario) no es necesario para derivar clave y acceder a datos encriptados.

La forma en que Windows evita que esto suceda (o, al menos, como se supone que debe suceder, consulte esto para más detalles) es mediante el uso de diferentes algoritmos de hash para el hashing de contraseñas y la obtención de claves: las contraseñas se trocean utilizando hash NTLM (que es MD4) y las claves se derivan de la contraseña del usuario utilizando PBKDF2-SHA1. De esta manera, la obtención del hash de la contraseña no permitirá que el atacante calcule las claves de cifrado porque la contraseña original es necesaria para calcular la clave.

Los nuevos sistemas normalmente no deberían usar hashes sin sal para el hashing de contraseñas; en cambio, algo como bcrypt o scrypt es una alternativa más robusta.

Si el sistema está restringido y es beneficioso usar PBKDF2 tanto para el hashing de contraseñas como para la obtención de claves, se pueden usar diferentes sales para diferentes propósitos: uno para la comprobación y verificación de contraseñas y otro para la derivación de claves; en este caso, el hash de contraseña comprometido no permitirá que el atacante calcule la clave derivada ya que la sal es diferente y aún se necesita la contraseña original para calcular PBKDF2 con otro valor de sal.