Almacenamiento de datos asimétrico + ¿Almacenamiento de contraseña sin hash?

0

Editar: eliminó una parte de la pregunta original; Lo desglosaré en otra publicación.

Estoy siguiendo @ Respuesta de Polynomial para almacenar información en una base de datos. Aquí están mis requisitos:

  • Solo el usuario puede ver su información. El servidor solo ve datos revueltos.
  • Permite cambios de contraseña fáciles
  • Aceptar con "perdí tu contraseña, perdí tus datos"
  • Si es posible, no almacena un hash de la contraseña de usuario
  • Utilice solo un servidor y su propio espacio de almacenamiento

Esto es lo que tengo hasta ahora:

DB Table USER_DATA contiene ([clave XORed] [random IV] [datos secretos cifrados] [userID])

Entrada de datos

1. User enters (secret data) into a form.
2. User enters (user password)
3. Generate a strong (random key).
4. Encrypt (secret data) using (random key) and (random IV), as (encrypted secret data).
5. XOR hash of (random key) with hash of (user password) as (XORed key).
6. In the database, store in a new row: (XORed key),(random IV),(encrypted secret data), (userID)

Recuperar datos

1. Ask user for (user password).
2. Query database for (XORed key),(random IV),(encrypted secret data).
3. XOR hash (user password) with (XORed key) to retrieve the initial (random key)
4. Use (random key), (random IV) to decrypt (encrypted secret data).
5. Display decrypted data on screen.

Me gustaría solicitar comentarios sobre el sistema anterior, con respecto a su (1) seguridad y (2) eficiencia. También me gustaría conocer su opinión sobre el siguiente sistema:

Autenticación

La forma más simple sería almacenar un hash de la contraseña, autenticarse contra ella y crear una sesión para permitir la exploración de los registros. Cada registro se descifra y luego se muestra al usuario. Sin embargo, dado que la contraseña se utiliza para descifrar toda la información del usuario, estoy tratando de evitar almacenar su hash: Tengo curiosidad si es posible con un solo servidor involucrado . Aquí hay un sistema en el que pensé, pero romperlo requeriría exactamente el mismo esfuerzo de forzar brutalmente un hash:

Inicio de sesión inicial del usuario

1. Ask user for (user password)
1. Create a strong (random key)
2. XOR (user password) with (random key) into (XORed key).
   Store this value in the database.
3. Create a (random hash).  Store in database.
4. Encrypt (random hash) with (random key) and (random IV)
   as (Encrypted random hash).  Store in database.

Así que ahora tenemos en la base de datos:     Tabla USER_AUTH ([clave XORed] [hash aleatorio] [hash aleatorio cifrado] [random IV])

En los inicios de sesión posteriores, la contraseña que proporciona el usuario está XORed con (clave XORed) para recuperar (clave aleatoria). (clave aleatoria) se utiliza para descifrar (hash aleatorio cifrado). Si el valor descifrado es el mismo que (hash aleatorio), la contraseña es correcta.

    
pregunta David_Springfield 08.05.2014 - 03:40
fuente

2 respuestas

1

Lo que probablemente quieras hacer es usar un algoritmo Key Wrap , pero no es absolutamente necesario. Me parece razonable que pueda hacer lo siguiente para el cifrado:

  1. Calcule una clave de usuario a partir de la contraseña del usuario, usando algo fuerte como PBKDF2.
  2. Genera una clave de datos aleatoria .
  3. Cifre la clave de datos con la clave de usuario , esto se almacenará como la clave incluida .
  4. Genere un HMAC a través de la clave envuelta con la clave usuario clave . Esto será almacenado para la autenticación. (Aún debe seleccionar la fila por otro mecanismo).
  5. Cifre los datos con la clave de datos .
  6. Almacene la sal PBKDF2, clave envuelta , hmac, IV y datos cifrados.

Descifrado:

  1. Seleccione la fila relevante de la base de datos.
  2. Usando el salt, recalcular la clave de usuario a partir de la contraseña.
  3. Verifique el HMAC en la clave envuelta utilizando la clave de usuario . Este es el paso de autenticación.
  4. Use la clave de usuario para descifrar la clave incluida , revelando la clave de datos .
  5. Descifre los datos utilizando la IV y la clave de datos .
respondido por el David 09.05.2014 - 06:07
fuente
0

Veo dos fallas en este sistema:

1) No menciona ninguna forma de asociar filas en la base de datos con un usuario determinado (es decir, el paso 2 en el proceso de "recuperación de datos").

2) Cada clave aleatoria es XORd con el mismo valor (la contraseña del usuario). Dado que se puede suponer que las claves aleatorias se distribuyen uniformemente, un atacante que puede determinar que varias filas de la base de datos pertenecen al mismo usuario puede recuperar la contraseña del usuario mediante un análisis estadístico trivial. Cuantos más datos almacene el usuario, más fácil y preciso será este análisis.

    
respondido por el Mark 08.05.2014 - 08:39
fuente

Lea otras preguntas en las etiquetas