Conceptos de un sistema seguro para compartir notas

3

Estoy tratando de diseñar un sistema que permita que los miembros del personal de nuestra pequeña empresa compartan de forma segura la información confidencial del cliente (texto) y los vean en una página web junto con las comunicaciones menos sensibles. Tengo la intención de usar PHP porque es lo que mejor conozco.

El principal desafío es que los datos deben almacenarse en el servidor, pero deben consumir mucho tiempo para que sean útiles si el servidor se ve comprometido.

Mi idea es la siguiente:

  1. Cuando se crea un usuario del personal, eligen una contraseña segura y se procesa utilizando bcrypt (12) y se almacena en nuestra base de datos. La contraseña simple también se usa para crear un par de claves RSA de 4096 bits utilizando OpenSSL. Ambas claves se almacenan en el servidor.

  2. Cuando se crea una nota segura, se cifra con la clave pública de cada miembro del personal y cada copia se almacena en la base de datos.

  3. Cuando un miembro del personal inicia sesión, su contraseña simple se compara con el hash para ver si coinciden. Si lo hacen, la contraseña simple, la IP del cliente y la ID de usuario se serializan y se cifran simétricamente utilizando mcrypt. La clave utilizada para cifrar la cadena se almacena en el sistema de archivos del servidor. El cipertexto se envía como una cookie al cliente.

  4. Cuando un miembro del personal accede a otra página, el servidor descifra la cookie y usa la contraseña simple y la clave privada del usuario para descifrar cualquier información confidencial en esa solicitud y envía la información confidencial al navegador del usuario.

Todo será sobre HTTPS con cifrados seguros.

Soy consciente de que esto es probablemente muy difícil de hacer completamente seguro, pero me gustaría saber si alguien puede detectar algún defecto evidente en esta configuración que pueda mejorarse razonablemente. En general, también sería útil saber cuán útil es una clave privada sin la contraseña segura asociada.

    
pregunta James 17.07.2015 - 11:53
fuente

2 respuestas

1

El problema general que veo con su solución es que las operaciones de contraseña se realizan en el servidor (por ejemplo, las contraseñas de los usuarios se pasan al servidor para su verificación), sin embargo, su modelo de amenaza es proteger los datos en el caso de un servidor compromiso.

Si el servidor está comprometido, solo pueden agarrar las contraseñas de los usuarios cuando el cliente las envíe para su comprobación.

Para implementar el tipo de solución del que está hablando (es decir, que es resistente al compromiso del servidor), necesitará que todas las operaciones criptográficas se realicen en el lado del cliente, para que el servidor no vea las contraseñas. . Vale la pena señalar que este tipo de solución es bastante difícil de implementar en la práctica, ya que necesita que los clientes puedan operar sin confiar en el servidor (por ejemplo, para las actualizaciones de código); de lo contrario, un atacante que haya comprometido el servidor podría hacer algo. como empujar una actualización de cliente con una puerta trasera en él.

    
respondido por el Rоry McCune 31.07.2015 - 22:34
fuente
1

Su sistema tiene fallas en los primeros dos pasos porque está almacenando las claves con los datos cifrados en el mismo sistema. Si un atacante compromete el servidor, solo puede buscar las claves y usarlas para descifrar las notas secretas. Es difícil lograr lo que quiere hacer sin que todos los usuarios almacenen una clave privada para el cifrado en su dispositivo.

Como no puedo comentar sobre tu pregunta original, alguna información adicional sería útil para hacer una recomendación firme. ¿Necesita que los usuarios puedan acceder a este sistema desde cualquier dispositivo? ¿Se enfrenta el sistema internet? ¿Aproximadamente cuántos usuarios soportará el sistema?

    
respondido por el Justin Moore 31.07.2015 - 22:24
fuente

Lea otras preguntas en las etiquetas