Diseño de alto nivel para aplicaciones web seguras

2

Estoy buscando algunos consejos sobre el diseño de una aplicación web segura para almacenar contraseñas. ¿Por qué reinventar la rueda? Porque no confío en un tercero con todas mis contraseñas.

Aquí están mis pensamientos:

  • Hay 3 componentes principales: Cliente, Servidor de aplicaciones, Servidor de base de datos. Idealmente, me gustaría que el sistema fuera lo suficientemente robusto, de modo que si el Servidor de aplicaciones o el Servidor de bases de datos se ve comprometido, el atacante no obtiene todos los datos (si el cliente está comprometido, no puedo ver ninguna forma de proteger los datos).
  • Para lograr esto, creo que hacer todo el cifrado en el Cliente tiene sentido. Por lo tanto, si el Servidor de base de datos está comprometido, solo obtendrían datos cifrados, y si el Servidor de aplicaciones está comprometido, no obtendrían las claves de cifrado porque el Cliente las guarda.
  • Eso crea al menos 2 problemas:

    • En este contexto,

      crypto del lado del cliente significa javascript crypto que es problemático . Aquí es cómo planeo solucionar algunos de los problemas principales.

      • No es bueno CSPRNG. Solo use los navegadores con getRandomValues () y use una biblioteca criptográfica js que lo admita.
      • Hombre en el medio. Forzar TLS para todas las conexiones (no ayuda si el servidor de aplicaciones está comprometido, por supuesto).
      • Vulnerabilidad de XSS. Escriba una secuencia de comandos de usuario complementario (Greasemonkey) que calcula los hashes de cada página en la aplicación y alerta al usuario cuando cualquier contenido de la página ha cambiado. Obviamente, esto dará lugar a falsos positivos cuando realice actualizaciones, pero debería permitirle detectar si alguien ha modificado su código en el Servidor de aplicaciones o ha inyectado con éxito algún contenido en la página.
    • La búsqueda de datos encriptados es complicada .

      • Todavía no tengo soluciones concretas para esto, pero si el plan general parece factible, hay buenas opciones por ahí.

Me doy cuenta de que esta pregunta es un poco amplia, así que siéntete libre de cerrarla si no es una buena opción para el sitio. Solo espero obtener una orientación general sobre lo que podría faltar o dónde están los agujeros en mi plan.

Actualización: Gracias a todos por los comentarios tan útiles. A la luz de algunas de las cuestiones planteadas, mi nuevo plan es hacer que todo sea mucho más simple. Mantenga un archivo JSON único, comprimido y cifrado en el servidor. Escribe una aplicación JS que se ejecuta localmente. Todo lo que hace es agarrar el archivo, descifrarlo localmente y luego volver a cargarlo cuando se realicen los cambios. ¿Pensamientos?

También, veo su punto de vista sobre el uso de un sistema bien probado y comprobado. Llámame parachoques de papel de aluminio, pero no puedo confiar en que alguien más tenga ese acceso. Todo lo que necesita es un empleado / colaborador disgustado o un agujero de seguridad para Que tengas un mal día.

    
pregunta Dominic P 22.01.2015 - 23:06
fuente

2 respuestas

2

Lo importante de una aplicación web es que es fundamentalmente inseguro si el código fuente (por ejemplo, JavaScript) se entrega al cliente a través de TLS. Puede ejecutar el mejor cifrado que desee, por ejemplo. las almohadillas de un solo uso o los cifrados de flujo en cascada, pero solo serán tan seguros como los cifrados y la "seguridad" en la suite TLS que es no está seguro contra las agencias de espionaje . Ha habido fallas fundamentales en TLS durante años . Probablemente malo por diseño porque NSA está en todo el comités de normas . También lea sobre el OpenSSL Heartbleed fiasco . Sin mencionar que todo el protocolo es trivialmente inseguro contra los adversarios del estado nación con solo una CA en su bolsillo . Todo lo que necesitan hacer es MITM la conexión e intercambiar algunas líneas de JavaScript poco fiable para robar las claves de cifrado y las contraseñas.

Usted tiene para hacer una extensión del navegador o ejecutar el código web localmente desde la ruta del archivo. Utilice CORS para realizar solicitudes al servidor de aplicaciones. Todo el código se carga y se ejecuta localmente. Todo el cifrado hecho del lado del cliente. Ningún código entregado por el servidor.

También puede agregar código personalizado en el cliente y el servidor de aplicaciones para cifrar el tráfico de transporte del cliente al servidor de la aplicación para proteger los metadatos y, si lo desea,

    
respondido por el NDF1 23.01.2015 - 00:15
fuente
1

Este es uno de los trabajos que mejor se dejan a los profesionales de INFOSEC. Demasiado para salir mal. Lo más cercano que he visto a lo que estás describiendo es Clipperz:

enlace

Ejecutando eso desde un archivo local codificado con el I.P. de su servidor. La dirección sobre SSL o IPsec sería un comienzo. Estoy de acuerdo con NDF1 en que una aplicación nativa es mejor debido principalmente a la reducción de la superficie de ataque & Mayor flexibilidad de desarrollo para la tecnología de ingeniería de seguridad. Es por eso que los proyectos como KeePass ya han creado administradores de contraseñas útiles y multiplataforma para nosotros. Yo diría que solo use una herramienta como KeePass o estudie los métodos de esas herramientas si elige rodar las suyas. Además, para ayudar, aquí está mi ensayo sobre varios enfoques de vanguardia y típicos para la seguridad de aplicaciones web con enlaces:

enlace

    
respondido por el Nick P 23.01.2015 - 03:14
fuente

Lea otras preguntas en las etiquetas