Guardar mensajes privados cifrados en la base de datos

10

No estoy seguro de si esta pregunta encaja mejor en StackOverflowSE o CryptoSE pero creo que este es el lugar correcto.

En un portal de la comunidad en línea, quiero guardar los mensajes privados de los usuarios cifrados en una base de datos para que no se pueda filtrar la información si alguien tiene acceso a la base de datos. Pero no tengo idea de cómo administrar las claves.

Cuando se envía un mensaje, se debe guardar cifrado en la base de datos y solo se debe poder descifrar si uno de los participantes solicita el mensaje. Obviamente, la clave no debe guardarse en la base de datos, ya que no tendría ningún sentido.

La forma en que se me ocurrió es guardar el mensaje con un algoritmo de clave simétrica y guardar la clave cifrada con un algoritmo de clave pública para cada participante (cada usuario tiene una clave pública).

Cuando se solicita un mensaje, se descifra utilizando la clave privada del usuario para obtener la clave simétrica. Sin embargo, no tengo idea de cómo crear / guardar una clave privada. No debe estar en la base de datos y debido a que la aplicación es multiplataforma (web, acceso móvil), no puedo guardarla en el dispositivo del usuario y se debe generar sobre la marcha utilizando una constante que proviene del usuario y no está guardado en algún lugar de la base de datos. La única constante que se me ocurre es la contraseña del usuario. Pero en caso de que la contraseña se pierda o se olvide, ya no hay forma de acceder a los mensajes.

Mi pregunta: ¿Hay otra manera de lograr esto? ¿O conoces otra constante que aún es privada?

Editar / Actualizar: Gracias por tus respuestas. Aquí hay una actualización:

¿Qué hay acerca de guardar la clave privada en db encriptada con una cadena aleatoria que se envía al usuario por correo electrónico una vez en el registro? Se aconseja al usuario que no borre ese correo. Si aún lo hace (parece bastante probable), entonces puedo culparla, bueno, no j / k, pero esa sería al menos la forma de recuperar los mensajes.

Aquí hay una subpregunta: a la aplicación solo se puede acceder a través de HTTPS o TCP / IP + SSL API. ¿Se guarda para en- / descifrar el mensaje en el servidor y enviarlo en formato plano sobre SSL? De lo contrario, tendría que buscar implementaciones (como GPG) para todas las plataformas (navegador, móvil, escritorio). Esto requiere almacenar la clave privada en RAM durante el tiempo que el usuario ha iniciado sesión (la contraseña se envía al inicio de sesión / inicio de sesión). Seguro que si alguien obtiene acceso de escritura al servidor (alterar la aplicación) o acceso de lectura al ram (o0) podría olfatear las teclas pero no creo que esto sea probable.

El mensaje debe estar * en * cifrado en el servidor (significa que se envía sin formato), ya que posiblemente el servidor lo deba enviar a los dispositivos móviles. (No importa si eso es seguro o no, quiero asegurarme de que nadie pueda usar un volcado de base de datos, no si Apple o alguien similar puede leerlo mientras se entrega).

Probablemente no necesito nada de esto, ya que lo más probable es que mis usuarios no se envíen mensajes secretos, pero en caso de una fuga, no estarán contentos. Es una comunidad para estudiantes locales y nunca se sabe lo que hacen los estudiantes aburridos de CS;).

    
pregunta Banane 07.11.2011 - 14:53
fuente

5 respuestas

6

Si la única forma de recuperar la contraseña es responder a una pregunta, puede cifrar la clave privada una vez con la contraseña y una vez más con la respuesta secreta y almacenar ambas versiones cifradas en la base de datos. Luego, si el usuario olvida la contraseña y usa la respuesta secreta para la recuperación, puede acceder a la clave privada y volver a cifrarla con la nueva contraseña (para uso normal). Si se cambia la respuesta secreta, se debe solicitar la contraseña y, por lo tanto, se puede volver a generar la versión que está cifrada con la respuesta.

Esto tiene (al menos) dos problemas. La respuesta 'secreta' a menudo no será tan difícil de descifrar. Esto podría solucionarse parcialmente utilizando PBKDF2 con un gran número de iteraciones (ya que esta opción se usaría con poca frecuencia). Otro problema es, obviamente, si por alguna razón desea restablecer la contraseña de un usuario manualmente (es decir, le han convencido de su identidad sin saber la respuesta secreta), entonces no podrá recuperar los mensajes. Pero dependiendo de los compromisos que esté dispuesto a hacer, podría ser útil a pesar de estos problemas.

    
respondido por el resistor 08.11.2011 - 10:45
fuente
4
  

cifrado en una base de datos para que la información no se pueda filtrar si alguien tiene acceso a la base de datos. Pero no tengo idea de cómo administrar las claves.

Le recomendaré que eche un vistazo a 2 libros:

Criptografía en la base de datos . Este libro explica cómo administrar claves y administrar proveedores de servicios criptográficos. El código provisto es Java, pero parece razonablemente compatible con .NET. Este libro está dirigido a la seguridad, la privacidad es irrelevante.

Bases de datos translúcidas . Este libro está dirigido a hacer que los datos sean útiles y utilizables por usuarios autorizados, pero inútiles para ladrones y fisgones. Este libro apunta más a la privacidad con seguridad en segundo lugar. Tengo la edición anterior.

    
respondido por el Tangurena 08.11.2011 - 22:46
fuente
4
  

La única constante que puedo encontrar es la contraseña del usuario. Pero en caso de que la contraseña se pierda o se olvide, ya no hay forma de acceder a los mensajes.

Esta respuesta resuelve el problema de la necesidad de poder recuperar manualmente los mensajes, una vez que se olvida la contraseña. Si necesita alguna forma automatizada que aún mantenga el excelente nivel de seguridad, es posible que no tenga suerte. Esto es para la recuperación manual por los administradores.

Puede almacenar una copia encriptada asimétricamente de las claves que se generaron usando la contraseña.

(Hablando en general) La "encriptación asimétrica para encriptar la clave generada por contraseña" no se puede realizar ingeniería inversa.

Por lo tanto, es necesario que almacenes la clave "descifrado para acceder a la clave generada por contraseña" en algún lugar.

Esto se puede almacenar en papel o en una unidad flash dentro de una caja bloqueada.

Esto permite una protección completa contra alguien que adquiere un acceso de solo lectura, a menos que encuentre los mensajes en su intercambio, o un montón o volcado de núcleo. Si tiene suficiente RAM y está lo suficientemente paranoico, puede considerar la posibilidad de desactivar el intercambio, y si nunca utiliza el volcado de pila o el núcleo, también podría deshabilitarlos.

Alguien con lectura / escritura puede cambiar sus programas para almacenar o enviar los mensajes de forma permanente a medida que se descifran. Si desea poder luchar contra eso, deberá almacenar la (s) suma (s) de verificación de todos los ejecutables (¿incluso el sistema operativo?) Y verificar manualmente cada vez que la suma de control cambie que fue algo que hizo, y no un robo. Esto podría darle la oportunidad de deshacer el daño antes de que salgan muchos datos.

    
respondido por el George Bailey 08.11.2011 - 23:35
fuente
3

Hay muchas respuestas posibles complicadas para esto, pero le daré una simple que no depende de la interacción del usuario que no sea el proceso de inicio de sesión normal:

Cuando un usuario inicia sesión, genere la clave de cifrado simétrica usando su contraseña a través de PBDKF2 con algún tipo de valor de sal.

La siguiente parte es una pregunta de compromiso de seguridad sobre dónde almacenar esa clave. Preferiría almacenarlo como una cookie en la máquina del usuario que dure tanto como lo hacen sus credenciales de inicio de sesión. Dado que la clave se crea con un sal aleatorio que se guarda en el servidor y nunca se revela y el descifrado solo puede ocurrir con la autenticación, no expone al usuario a ataques de fuerza bruta sin conexión razonables en su contraseña.

Finalmente, no expone al usuario a un mayor riesgo de acceso a sus datos que cualquier otra sesión de inicio de sesión común. Si se incauta su computadora y se registra, se logra el acceso. Si su computadora está ocupada y no ha iniciado sesión, no se puede acceder. Si sus datos se solicitan por medio de una citación, su publicación no ayudará a descifrarlos sin la contraseña del usuario (con la esperanza de que sea sólida) para generar la clave adecuada. Además, si te sientes particularmente malhumorado, podrías no divulgar la sal a menos que la citación lo cubra o de que tus máquinas hayan sido incautadas.

¿Sobre esa otra constante privada? No existe No puede mantener en secreto una clave de cifrado y estar disponible para que el usuario la reemplace. O puede mantener la llave en depósito para descifrar si pierden su contraseña, o no tendrán suerte si pierden su clave / contraseña. Cualquier otra cosa involucra complicados aros como SSSS y convencer a los amigos para que respondan que eres tú y que deberías poder leer las cosas. . Entonces tienes que confiar en ellos.

    
respondido por el Jeff Ferland 07.11.2011 - 17:01
fuente
3

Los controles de seguridad se han relacionado con el valor del activo que está protegiendo.

No tiene sentido comprar $ 1,000 de bloqueo seguro para proteger $ 100 activos.

En la situación que describe (comunidad para estudiantes locales), diría que incluso un simple cifrado simétrico sería más que suficiente.
Sólo para comprobar:

¿Almacena TODA LA PII (información de identificación personal) encriptada? ¿Realiza pruebas de penetración periódicas para garantizar que su sitio esté protegido? ¿Endureces tus servidores?

Invertiría en estos primero antes de implementar un mecanismo de cifrado público-privado sofisticado.

Creo que terminarás con un sistema que no funcionará; los usuarios olvidarán las claves y matarán su sistema de soporte.

    
respondido por el AaronS 09.11.2011 - 16:33
fuente

Lea otras preguntas en las etiquetas