Proteger los datos del usuario contra un atacante que puede obtener la raíz del servidor

3

Estoy diseñando una aplicación web que manejará datos muy confidenciales y los almacenará en nombre de sus usuarios. Una especie de caja fuerte en línea, por así decirlo.

Los datos seguros de un usuario solo deben ser visibles para ella, ni siquiera para el software del servidor o el propietario. Esto abre el camino a prácticas de seguridad sólidas, como el uso de una contraseña de usuario final para cifrar / descifrar directamente sus datos, o mejor aún, para cifrar una clave simétrica utilizada para cifrar sus datos. Esto último permitiría cambiar la contraseña sin volver a cifrar todos los registros en la base de datos.

¿Puedo garantizar que un atacante no pueda acceder a los datos protegidos, incluso si obtuvieran acceso de root a mi servidor?

Se me ocurrió la idea de que necesito cifrar / descifrar los datos del usuario en el lado del cliente. Los navegadores y el hardware modernos hacen posible que la contraseña y la clave de cifrado del usuario nunca salgan de su navegador. Todas las otras técnicas que se me ocurren tienen defectos fatales, por lo que un atacante podría leer la memoria de mi software de servidor en ejecución y encontrar la clave de cifrado.

Pero ¿cómo puedo evitar que el atacante plante un error web en mi sitio web, o simplemente cambie mi script del lado del cliente, para enviar las claves de cifrado de los usuarios?

¿Existe alguna tecnología, compatible con uno o más navegadores, en la que pueda solicitar que todos los scripts del lado del cliente de mi sitio web estén firmados con algún certificado mío? Por el bien de esta pregunta, suponga que mis usuarios confían en mí para escribir un buen software, por lo que confiarían en mi certificado.

¿Hay una extensión de navegador que haga tales comprobaciones, que podría recomendar a mis usuarios que instalen?

En caso de que no exista, ¿cómo se aborda esta amenaza en la industria? ¿La auditoría es la única solución? Por ejemplo, revisando mi sitio web periódicamente desde direcciones IP externas, para asegurarse de que los scripts del lado del cliente no hayan cambiado el hash criptográfico.

¿Debo renunciar a la idea de hacer algo como esto con tecnologías web abiertas y resolver el problema utilizando un sistema de distribución de software confiable como las tiendas de aplicaciones de Apple / Google? ¿Esto solo traslada el problema al servidor de otra persona o realmente aborda el problema subyacente?

¿Puede recomendar algún buen práctico libros / blogs / artículos sobre el tema?

    
pregunta Tobia 07.11.2014 - 23:51
fuente

2 respuestas

8

Quizás uno de los casos de estudio más interesantes de este tipo de situación es www.blockchain.info, que emplea cifrado del lado del cliente y obviamente tiene mucho en juego: el contenido de las billeteras de bitcoin de millones de usuarios. p>

Su enfoque inicial era una extensión del navegador que verificaba los recursos fuente del sitio web en comparación con una lista predefinida de sumas hash: enlace . Este enfoque duró un año o dos, cuando fue desaprobado en favor de una extensión del navegador que empaqueta todo el código base del lado del cliente en la propia extensión.

Lamentablemente, no puedo encontrar un blog o artículo de ellos que explique este cambio, pero buscar en Google para estos términos encontrará comentarios que sugieren que el enfoque del "verificador" no fue completamente una prueba a prueba de balas.

El enfoque de extensión ciertamente reduce el vector de ataque, ya que el código responsable del cifrado del lado del cliente solo se descarga una vez, y además porque las tiendas de aplicaciones como Chrome Web Store o Google Play requieren que las actualizaciones se firmen con la misma clave que la versión inicial, que garantiza que las actualizaciones no se pueden alterar, por supuesto, suponiendo que pueda mantener segura su clave privada y que no se encuentren vulnerabilidades en el navegador ni en la plataforma de la tienda de aplicaciones.

Definitivamente estaría interesado en leer el famoso artículo "Criptografía de Javascript considerada dañina" y los muchos seguimientos y refutaciones: enlace

    
respondido por el david 08.11.2014 - 01:26
fuente
1

El problema con un enfoque de extensión del navegador es que muchos usuarios no estarían dispuestos o permitirían instalarlo (p. ej., al iniciar sesión en su lugar de trabajo no podrían instalar extensiones). También tiene que distribuir de forma segura la extensión, que es un problema en sí mismo.

Un enfoque de banca en línea que he visto es que el banco coloca una ubicación / navegador personalizado en un CD-ROM o dispositivo USB del tamaño de una tarjeta de crédito. Cada navegador tiene claves SSL únicas de usuario y se ejecuta fuera de los medios de solo lectura. El servidor web puede verificar que la conexión del navegador pertenece al cliente específico. También podría tener complementos personalizados para verificar los recursos web.

Estos días son algo así como Apache Cordova o PhoneGap, que incluye HTML + JS en aplicaciones móviles creadas para todas las plataformas móviles, es probablemente un lugar ideal. . Soy un cliente de HSBC y su aplicación se ve y se siente como tal aplicación HTMl + JS empaquetada. Hará "descargas de actualizaciones" ocasionalmente cuando la aplicación se abra (lo que no hacen las aplicaciones móviles nativas) posiblemente descargando nuevos recursos web en el almacenamiento local. Todas las aplicaciones de la App Store están firmadas y las violaciones de las grandes tiendas de Apple o Google serían una gran noticia y se arreglarían rápidamente. Pueden permitirse más auditorías y recibirán más atención de lo que lo hacen solo.

Puede ejecutar protocolo de contraseña SRP en lugar de enviar la contraseña en texto sin formato. Consulte Can ¿Utilizo la misma contraseña tanto para SRP como para el cifrado del lado del cliente? . El mensaje de texto le envía al usuario un código de cuatro dígitos para que ingrese al intentar iniciar sesión y también tendrá dos factores de autenticación.

Si no puede ir a la ruta de Córdoba y sus usos insisten en usar navegadores web arbitrarios, entonces, el riesgo es que su máquina esté llena de virus y no esté parcheada. Puede instalar parches en sus servidores, pagar por las pruebas de penetración y suscribirse a un servicio que supervise sitios falsos, registros de DNS similares, DNS envenenado, correos electrónicos de phishing, etc. NetCraft proporciona dichos servicios. Internamente, puede ejecutar openource tripwire para verificar los hashes de todos los archivos en sus casillas de primera línea para confirmar que no se hayan cargado kits de raíz o errores web. Si el usuario tiene una PC comprometida que ejecuta un registrador de teclado o un teléfono roto en la cárcel, no hay nada que pueda hacer por ellos. La ejecución de SRP, la autenticación de dos factores, el cifrado en el lado del cliente y la detección de intrusiones tripwire de código abierto en su sitio web puede ser suficiente.

    
respondido por el simbo1905 21.05.2015 - 00:21
fuente

Lea otras preguntas en las etiquetas