Mantener la privacidad de los datos del usuario en un entorno de nube como Google App Engine

Question

Mantener la privacidad de los datos del usuario en un entorno de nube como Google App Engine

#1 de D.W. (3 votos)
#2 de Thomas Pornin (1 votos)

7

Estoy escribiendo una aplicación Java de código abierto para Google App Engine (GAE). La aplicación permitirá a los usuarios crear contenido que pretende ser privado. Quiero ofrecer garantías razonables de que nadie (incluyéndome a mí, como administrador del sitio) podrá leer contenido privado que pertenezca a otra persona. ¿Cuál es la mejor manera de lograr esto?

El sitio se servirá utilizando https. Los usuarios iniciarán sesión en mi aplicación utilizando OpenId, por lo que no tengo el control de sus credenciales de inicio de sesión (no tengo su contraseña).

Basándome en la investigación que he realizado hasta ahora, creo que una solución podría ser cifrar los datos escritos en el almacén de datos de GAE utilizando una clave de cifrado basada en contraseña. El usuario elegiría una contraseña por separado que se usará solo para cifrar sus datos privados. Para generar la clave de encriptación, debería codificar la contraseña de alguna manera (¿quizás bcrypt?). Los datos escritos en el almacén de datos de GAE luego se cifrarían utilizando la clave de cifrado más un salt, y la sal se almacenaría junto con el blob cifrado. Nunca almacenaría permanentemente la contraseña o la clave de cifrado, pero probablemente necesitaría mantener la clave de cifrado en la sesión mientras el usuario está conectado.

¿Es esta una buena solución? ¿Hay otras soluciones que debería considerar en su lugar?

También apreciaría cualquier puntero a las aplicaciones de código abierto existentes que hacen este tipo de cosas correctamente.

Editar (20 de diciembre de 2011):

Intentaré aclarar lo que estoy buscando.

Google App Engine admite dos funciones: usuarios y administradores. En este caso, un usuario es cualquiera que elige iniciar sesión en el sitio a través de OpenId. Un administrador es un tipo especial de usuario que también obtiene acceso a la consola administrativa de la aplicación. Entre otras cosas, los administradores pueden ver los registros y manipular directamente el almacén de datos de back-end (lectura y escritura). Algunos administradores, llamémoslos administradores / desarrolladores, también tienen la capacidad de implementar un nuevo código.

Se puede esperar que los usuarios creen contenido público y privado. Quiero que los usuarios se sientan seguros de que el contenido que marcan como "privado" no puede ser visto por nadie más.

Reconozco que un administrador / desarrollador malicioso podría cargar un código con una puerta trasera para burlar el diseño de privacidad. Sin embargo, ese problema tendrá que resolverse a través de la auditoría. Debido a que el código es de código abierto, los usuarios preocupados por la implementación del software tienen la oportunidad de revisar el código y convencerse de su integridad.

También reconozco que una gran parte de este derecho es simplemente un buen diseño de la aplicación. Por ejemplo, el back-end debe requerir autenticación y no debe permitir que los usuarios autenticados vean datos que no son de su propiedad. También debe haber una cobertura de prueba suficiente para confirmar que esta funcionalidad funciona según lo previsto. Esta parte del diseño de la aplicación ya está en su lugar.

Cuando hice esta pregunta, esperaba encontrar una solución que ofreciera un mayor nivel de seguridad. Estoy buscando un diseño que proteja, tanto como sea práctico, contra usuarios malintencionados, administradores maliciosos y errores de software no intencionales en los sistemas que controlo. Si al mismo tiempo, esta solución también ofrece cierta protección contra proveedores de sistemas malintencionados o incompetentes (es decir, el personal de Google busca cosas que no deberían, o errores de App Engine que revelan inadvertidamente mis datos), eso es aún mejor.

Me doy cuenta de que no puedo protegerme contra todos los vectores de ataque en una aplicación como esta, y ciertas soluciones serán demasiado feas, o demasiado molestas desde la perspectiva del usuario, para ser prácticas. Puede que no haya una solución que sea "mejor" que la que ya he implementado. En ese caso, me gustaría documentar el razonamiento detrás de esa conclusión. Sin embargo, si hay una solución razonable, me gustaría encontrarla.

password-management hash cryptography appsec databases

pregunta Ken Pronovici 19.12.2011 - 20:37

fuente

2 respuestas

Lea otras preguntas en las etiquetas password-management hash cryptography appsec databases

configuración de seguridad php.ini después del ataque cifrado de disco completo de Android

score 3 · Answer 1

No puedes. Básicamente, no existe un mecanismo técnico que le impida leer el contenido del usuario, si quisiera y fuera malicioso.

Aquí, veamos algunos intentos obvios y entendamos por qué no funcionan realmente:

Puede cifrar los datos del usuario con una clave que es un código fijo en su programa, y almacenar en la base de datos en forma cifrada, para evitar que eche un vistazo a los datos del usuario. Pero luego su código tendrá la clave de descifrado, por lo que siempre puede mirar la clave de descifrado y luego podrá ver los datos del usuario. No funciona.

(Tener el programa para generar la clave para usted tampoco funciona, porque ¿dónde guardará la clave para su uso futuro? En cualquier lugar donde pueda guardar la clave, puede leer).
Puede pedirle al usuario que proporcione una frase de contraseña, derivar una clave de cifrado a partir de la frase de contraseña del usuario, cifrar los datos del usuario con esta clave y luego almacenarla en la base de datos en forma cifrada. Pero entonces su código ve la clave de descifrado. Puede modificar su código para recopilar y registrar las contraseñas de los usuarios, lo que le permitirá leer los datos de los usuarios. Los usuarios no tendrían forma de detectar esto. No funciona.
Puede enviar código Javascript al navegador del usuario. El código de Javascript podría pedirle al usuario una frase de contraseña, derivar una clave de cifrado a partir de la frase de contraseña del usuario y cifrar los datos (todo se ejecuta en el navegador, por lo que la frase de contraseña del usuario nunca abandona su navegador). El Javascript podría luego enviar los datos del usuario, en forma encriptada, a su servidor para almacenarlos. Esto suena atractivo. Sin embargo, hay un problema serio con ello. Si fuera malintencionado o snoopy, podría modificar fácilmente el código de su servidor para enviar un nuevo Javascript a los usuarios, que recopila sus contraseñas y envía una copia a su servidor. Eso te permitiría leer los datos de los usuarios. Si bien podría decir "Caramba, yo nunca haría eso", el punto es que los usuarios no tendrían forma de detectar esto, por lo que no tienen forma de verificar si usted es honesto o no, y no hay ningún mecanismo técnico que lo impida. De ser deshonesto. No funciona.

Entonces, como puede ver, no hay una solución técnica para este problema que realmente le impide leer los datos del usuario. Si realmente quisiera leer los datos de los usuarios, podría hacerlo, e incluso podría hacerlo de una manera que los usuarios no notaran. ¿Qué garantías tienen los usuarios de que no harás esto? Bueno, tienen que confiar en ti para ser honesto. Los mecanismos técnicos no pueden resolver el problema.

Ahora, todavía hay una buena razón para cifrar. Si es honesto y desea proteger a sus usuarios, no de una versión deshonesta de usted, sino de errores involuntarios que pueda cometer o posibles violaciones de seguridad de los contenidos de la base de datos del servidor, bueno, ese es un problema que puede surgir. Resuelto, en parte, utilizando el cifrado.

Pero el problema particular que mencionó no es uno que realmente pueda resolverse solo a través de la criptografía, en la práctica.

score 1 · Answer 2

Si desea que los usuarios se sientan seguros , entonces es cuestión de agregar algunas fotos de candados en toda la interfaz. Esto es psicología , no seguridad . Tomemos el ejemplo de los bancos del siglo XIX, que siempre construyeron sus oficinas en una arquitectura neoclásica, con grandes pilares de piedra y pisos de mármol: esto fue así para que los clientes, inconscientemente, vinculen al banco con las nociones de solidez y longevidad. Noción crucial en los Estados Unidos antes de la creación de la FDIC en 1933.

Si desea convencer a terceros con conocimientos técnicos de que no está interfiriendo con los llamados "datos privados del usuario", bueno ... lo más probable es que no tenga suerte. Agregar cifrado y hashes no ayudará; Al ser sysadmin / developer, todavía tiene el control y técnicamente puede hacer todo lo que quiera. La acumulación de capas de criptografía injustificada solo lo hará parecer un poco incompetente en cuestiones de seguridad (al menos a los ojos de los profesionales de seguridad de TI), que a su vez disminuirá la confianza, no la aumentará.

Lo mejor que podemos tener ahora para evitar errores, agujeros y puertas traseras es hacer muchas auditorías . Haga que el código fuente del servidor sea debidamente inspeccionado. Edite los procedimientos escritos para cada acción administrativa que se realice en los servidores y asegúrese de que se sigan; es decir, contratar a un auditor externo que será testigo físico de todas las operaciones. Imponga el control dual (por ejemplo, la contraseña del administrador es larga y la gente conoce solo la mitad, por lo que se necesitan dos operadores para escribir la contraseña). Requiere autorización de seguridad (incluida la situación de la deuda) para todos los desarrolladores y administradores de sistemas. Existe un marco para eso llamado Webtrust . Dos advertencias importantes:

Será costoso, largo, increíblemente complejo, y destruirá tu alma permanentemente.
No es bueno. Es lo mejor que tenemos.