¿Es seguro usar diferentes claves derivadas pero a partir de la misma frase de contraseña para el cifrado AES CBC seguido del hashing HMAC SHA256?

Navega tus respuestas
5

Estoy trabajando en una aplicación de administrador de listas multiplataforma (JS / iOS / Android) que persiste en los datos a través de una API REST y quiero asegurarme de que los datos textuales estén correctamente cifrados en el lado del cliente para que no haya forma de descifrarlos. Los datos en el lado del servidor y en el desafortunado caso de que la base de datos sea robada, no vale la pena dedicar ningún esfuerzo a intentar descifrarlos.

Muchos meses de investigación, prueba y error me han llevado a decidir que el cifrado AES en el modo de operación CBC es la mejor opción para este propósito debido a su solidez y amplia adopción en todas las plataformas. Decidí hacer una derivación de claves basada en el algoritmo similar de OpenSSL para tener una herramienta de línea de comandos confiable para probar la exactitud de mi implementación.

Lo único que queda es asegurar de alguna manera la validez de la frase de contraseña de cifrado proporcionada por el usuario, que nunca llegará directamente al lado del servidor. La mejor idea que se me ha ocurrido hasta ahora es descifrar varios elementos de la lista después de iniciar sesión para probar si se pueden descifrar correctamente aplicando el hash HMAC en el texto cifrado, que a su vez requiere el almacenamiento del hash HMAC en el lado del servidor. / p>

Tengo un par de preguntas:

  • ¿hay alguna otra manera de garantizar de forma segura la validez de la frase de contraseña proporcionada después de un inicio de sesión exitoso?
  • ¿es seguro reutilizar la misma frase de contraseña en el cifrado AES CBC como clave secreta en el hashing HMAC de los mismos datos cifrados?

He visto este subproceso TLS pero yo No es necesario el cifrado entre una configuración típica de cliente / servidor. En mi caso, el cliente cifra los datos, los almacena en la nube y, la próxima vez, el mismo cliente u otro cliente lo descifrarán. Por lo tanto, los apretones de manos y demás en TLS no tienen mucho sentido para mí.

Nota 1: intencionalmente la llamo una "frase de contraseña" para enfatizar que es diferente de la contraseña de usuario que se valida al iniciar sesión y se almacena como un hash en la cuenta del usuario.

Nota 2: En la parte superior de todo eso, las solicitudes viajarán a través de HTTPS. El punto anterior no es garantizar la seguridad del transporte, sino restringir la legibilidad de los datos al lado del cliente para obtener numerosos beneficios de seguridad.

Aprecio cualquier comentario. Gracias!

    
pregunta Norbert 10.09.2011 - 15:55
fuente

3 respuestas

7

Puede usar PBKDF2 con diferentes sales para derivar claves para el hashing y el cifrado. El propósito de las funciones PBKDF es derivar claves de pass (palabras | frases). Las sales deben generarse utilizando un PRNG criptográficamente fuerte, y deben ser largas (por ejemplo, siempre que sus claves). Tenga en cuenta que las sales para PBKDF2 no son necesariamente secretos, por lo que es seguro enviarlas al servidor si es necesario (al menos la sal utilizada como entrada para derivar la clave utilizada para HMAC).

    
respondido por el yfeldblum 11.09.2011 - 18:38
fuente
9

Estás rodando tu propia criptografía. No haga rodar su propio criptografía . En su lugar, le recomiendo que use PGP o GPG, o use su formato: a saber, el formato de archivo OpenPGP.

No debe usar la misma clave tanto para el cifrado como para la autenticación. No recomiendo usar la misma clave tanto para AES-CBC como para HMAC.

En cambio, sugiero que derive dos claves de la clave maestra. por ejemplo, K enc = AES (MK, 0), K auth = AES (MK, 1), donde MK es la clave maestra (una clave AES) y 0 , 1 son dos plaintexts AES diferentes. Ahora use K enc como su clave de cifrado para usar con AES-CBC, y use K auth como su clave de autenticación para usar con SHA1-HMAC o AES-CMAC.

Alternativamente, puede usar un modo de encriptación autenticada , como EAX, CCM, GCM o OCB. Encriptación autenticada se ocupa de obtener claves de una sola clave maestra, y se ocupa de proporcionar tanto la autenticación como la encriptación.

Parece que también estás cometiendo otro error: utiliza una frase de contraseña como clave de cifrado. Debe tratar de evitar el uso de contraseñas como claves de cifrado .

¿Hay alguna posibilidad de que puedas usar el cifrado convencional GPG? GPG ha sido escrito y examinado cuidadosamente para encargarse de todos estos problemas.

    
respondido por el D.W. 10.09.2011 - 23:46
fuente
1

Sí, puedes usar ese patrón.

  • Proporcionar a un usuario texto sin formato y un HMAC de ese texto no revela la clave del HMAC.
  • Proporcionar a un usuario texto sin formato no les permite derivar el HMAC sin conocer la clave.
  • Proporcionar a un usuario un HMAC sin una clave no les permite probar el HMAC con ningún texto.

Con esos factores conocidos, proporcionar al usuario un HMAC y un cyphertext que use la misma clave no le da nada al usuario sin que ellos conozcan la clave. No hay nada allí que pueda reducir la cantidad de intentos necesarios para anular el cifrado.

La diferencia sustancial entre este esquema y proporcionar un simple hash del texto simple es que uno no puede intentar efectivamente forzar la tabla de fuerza bruta / arco iris el hash (aunque el mensaje es probablemente demasiado largo para eso).

Hay otros modos que cifran un mensaje de tal manera que se asegure la autenticidad. Estos se mencionan en las respuestas de otros y pueden ser más útiles dependiendo de sus necesidades. Sugiero investigar esos también.

    
respondido por el Jeff Ferland 11.09.2011 - 02:33
fuente

Lea otras preguntas en las etiquetas

Enviar una nueva contraseña por correo electrónico es una mala práctica, pero ¿qué hacer si el usuario olvidó su contraseña? ¿Deberíamos verificar las restricciones de contraseña en los formularios de inicio de sesión?