Manejo de datos confidenciales para una aplicación web

0

Le guardaré el detalle de los problemas, pero avíseme si necesita información adicional que no esté mencionando aquí.

La configuración básica es que tengo una aplicación web, y en el navegador el usuario ingresará información relativamente confidencial que se transmitirá al servidor a través de https. A diferencia de las contraseñas para los inicios de sesión, esta información enviada por los usuarios deberá estar disponible / legible para los usuarios en el futuro y, por lo tanto, encriptada de manera reversible.

He encontrado algunas publicaciones relevantes, pero no estoy seguro si las entiendo completamente. Mi pensamiento inicial fue el siguiente:

  1. Pídale al usuario que envíe un código de acceso junto con su información confidencial.
  2. En el lado del servidor, cifro la información confidencial usando su contraseña a través de AES, etc.
  3. Almaceno la información cifrada en mi base de datos y descarto el código de acceso.
  4. Cuando el usuario necesita ver la información confidencial, le pido que escriba el código de acceso nuevamente, que luego se envía al servidor.
  5. Una vez que obtengo el código de acceso, lo uso para descifrar la información de mi base de datos y enviar la información descifrada al navegador.

La conclusión es que nunca almaceno el código de acceso utilizado como clave para el cifrado . Ahora esto va a sonar ingenuo y amplio, pero ¿puede alguien darme una idea de si este procedimiento sería seguro o no? Supongo que, como la clave no se encuentra en ningún lugar del servidor, la información es tan segura / insegura como el propio método de cifrado AES.

¿Cómo codificar datos confidenciales en la base de datos de una aplicación web?

He estado leyendo la respuesta del enlace anterior, que implica varias capas adicionales de cifrado. Probablemente pueda implementarlo, pero ¿son esos pasos adicionales necesarios para mi propósito? Y si es así, ¿cómo esos pasos lo hacen más seguro de lo que he descrito anteriormente? Por ejemplo, en el peor de los casos, si se compromete todo el servidor, ¿sería más conveniente este último método?

¡Gracias!

    
pregunta Michael Xu 24.01.2018 - 10:04
fuente

2 respuestas

-1

Creo que un problema principal para el primer enfoque es que una vez que el usuario pierde el código de acceso, no hay forma de recuperarlo (sin fuerza bruta). Sin embargo, dependiendo del tipo de información que pueda ser un requisito.

Por lo tanto, al llegar al artículo vinculado, se explicará cómo resuelve ese problema. Es más cómodo y le permite implementarlo en el esperamos algoritmo de cambio de contraseña ya existente para generar siempre una nueva KEK y volver a cifrar el DEK. Es menos probable que se olvide la contraseña

    
respondido por el Nico 24.01.2018 - 10:16
fuente
-2

Tienes dos problemas:

1) Si usa una clave generada a partir de una contraseña para cifrar los datos del usuario, deberá descifrar y cifrar todos los datos nuevamente si el usuario restablece su contraseña.

Solución : utilice el enfoque propuesto en el enlace que publicó (DEK y KEK).

2) Es común que los usuarios olviden sus contraseñas, especialmente si no se registran tan a menudo y el descifrado de datos siempre depende de la contraseña.

Solución propuesta : utilice algo que los usuarios casi no olviden, es decir, sus direcciones de correo electrónico.

Encriptación:

  1. Pida a los usuarios que ingresen su dirección de correo electrónico
  2. Concatene la dirección de correo electrónico con un salt y haga un hash para generar una clave que se utilizará para cifrar la contraseña
  3. Todo esto debe hacerse en el lado del usuario (no en el lado del servidor)
  4. Guarda el salt y la contraseña cifrada en su base de datos (no debe guardar sus correos electrónicos, ¿o sí?)

Si el usuario olvida su contraseña:

  1. Pídale al usuario que ingrese su dirección de correo electrónico
  2. Verifique la propiedad de la dirección de correo electrónico enviando un correo electrónico de verificación
  3. Use la dirección de correo electrónico junto con la sal que tiene para volver a generar la clave utilizada para descifrar la contraseña.

No desea generar KEK a partir de la dirección de correo electrónico porque siempre tendrá que verificar la propiedad del correo electrónico cada vez que el usuario inicie sesión en su aplicación web.

    
respondido por el daygoor 22.10.2018 - 09:15
fuente

Lea otras preguntas en las etiquetas