Cifrar los datos almacenados en una base de datos

3

Hace poco hablé con un cliente potencial que desea crear una base de datos que contenga datos bastante confidenciales. Uno de sus requisitos clave es que los datos almacenados se cifrarán de manera que solo el usuario podrá acceder a ellos. Incluso si hay algunas desventajas, pensé en cómo podría lograr esto y se me ocurrió el siguiente enfoque:

Cuando se crea un usuario, estoy creando un par de claves pública / privada para él. La clave privada se cifrará simétricamente con la contraseña del usuario. Todos los datos que se almacenan en la base de datos (muy probablemente, excepto la marca de tiempo y, por supuesto, la identificación) se cifran antes con la clave pública. Cuando el usuario inicie sesión, la contraseña se utilizará para descifrar la clave privada, que a su vez se puede usar para descifrar los datos de la base de datos al leerla. Toda la encriptación y el descifrado pueden ocurrir de manera transparente en la capa de acceso a datos.

Hay algunos inconvenientes importantes que deben abordarse aquí:

  • Tendremos que desentregar y cifrar la clave privada cuando el usuario quiera cambiar su contraseña
  • Si el usuario pierde su contraseña, no podremos reconstruir los datos
  • La clave privada o la contraseña del usuario deben almacenarse en texto sin formato temporalmente
  • Siempre que sospechemos que una clave privada ha sido dañada (en el sentido de robada) tendremos que volver a cifrar todos los datos de los usuarios

y, por supuesto, algunos más que aún no se me han acercado.

El primer problema es un inconveniente para nosotros, pero puede pasarle al usuario de forma transparente, por lo tanto, no es un gran problema.

El segundo es un poco más complejo. No queremos que el usuario pierda sus datos, pero tendremos que asumir que perderá su contraseña (el almacenamiento y / o el uso de una contraseña fija no son opciones por razones obvias, nunca). Una posible solución sería crear una frase de contraseña muy fuerte (más de 30 caracteres) que se usará para cifrar una copia de seguridad de la clave privada. Esto se puede enviar al usuario por correo postal o similar. El usuario puede usar esto para restaurar sus datos si olvidó su contraseña.

Tengo un mal presentimiento sobre no. 3, pero no tengo una mejor idea en este momento.

El cuarto problema nuevamente es un inconveniente para nosotros y puede llevarnos un tiempo, pero no debería ser un gran problema. El único problema es el factor humano aquí. Necesitaríamos que el usuario inicie sesión para realizar el nuevo cifrado y no podríamos hacerlo automáticamente.

¿Hay fallas serias en esto, especialmente en relación con la seguridad de los datos? ¿Es esta una buena idea de todos modos?

    
pregunta Paul K 14.08.2015 - 14:02
fuente

2 respuestas

3
  

Uno de sus requisitos clave es que los datos almacenados se cifrarán   de manera que solo el usuario podrá acceder a él.

La única manera de garantizar esto de verdad es que la clave de cifrado se encuentre en el cliente, bajo el control del usuario. Esto introduce (al menos) dos problemas -

  • Tener un cliente lo suficientemente grueso como para admitir la administración y descifrado de claves
  • Los usuarios perderán sus claves y, en consecuencia, sus datos

El primero tiende a descartar las aplicaciones basadas en el navegador (aunque estoy seguro de que alguien, en algún lugar, ha sido lo suficientemente inteligente como para encontrar una manera de hacerlo). La segunda es una implicación inevitable del requisito, y bien puede ser aceptable para los usuarios (un usuario con requisitos de secreto suficientemente estrictos puede preferir perder los datos que los comprometidos).

Las protecciones que ha ideado (usar la contraseña de usuario para proteger la clave) solo protegen al usuario de usted si es honesto. Si no es honesto, puede capturar su contraseña cuando desbloquee la clave, o capturar la clave desbloqueada cuando la esté usando. O tal vez sea honesto, pero hay un agente del gobierno detrás de usted con una orden judicial y / o un arma. De cualquier manera, si realmente quiere decir "cifrado de manera que solo el usuario podrá acceder a él", entonces el usuario debe ser el custodio de la clave.

(Ahora, de hecho, si le proporciona al cliente, debe confiar en que no lo hizo para capturar su clave, sus datos, etc.). Pero teóricamente , ya que tienen al cliente en sus manos, pueden analizarlo e intentar detectar este tipo de mal comportamiento por su parte, al igual que los proveedores de antivirus y personal de respuesta a incidentes forense analizan el código para ver qué está haciendo debajo del capó. Si la clave se almacena / usa en el lado del servidor. Realistamente pocas personas tienen las habilidades para hacerlo, y aún menos tienen la motivación, pero el hecho de que sea posible resulta en la percepción que se puede confiar en el cliente más que en el servidor en este escenario)

    
respondido por el gowenfawr 14.08.2015 - 14:57
fuente
0

Si va a ir por esa ruta, una función de derivación de clave (KDF) de la contraseña de los usuarios podría ser el camino a seguir. De esa manera, las claves de cifrado se generan a partir de la entrada del usuario para que no tenga que almacenar ninguna de las claves. Sin embargo, esto también tiene el problema de que si el usuario no puede recordar su contraseña, los datos se perderán y KDF también puede tener problemas de implementación.

más información sobre KDF's

Dicho esto, ¿por qué seguir esta ruta? La mayoría de las principales bases de datos tienen la capacidad de cifrar en reposo, así como cifrar sus copias de seguridad. Si tiene cuidado de implementar la seguridad adecuada en su sitio web, red y base de datos, sus usuarios finales no tendrán que preocuparse por perder sus datos o usted perderá sus datos ante piratas informáticos.

    
respondido por el Anthony 14.08.2015 - 15:23
fuente

Lea otras preguntas en las etiquetas