Cómo (programáticamente o por otros medios) encriptar o proteger los datos del cliente

5

Estoy trabajando en un proyecto web y quiero (en la medida de lo posible) manejar los datos de los usuarios de forma que se reduzcan los daños a la privacidad de los usuarios en caso de que alguien comprometa nuestros servidores / bases de datos.

Por supuesto, solo tenemos los datos de usuario que se necesitan para que el sitio web haga su trabajo, pero debido a la naturaleza del proyecto, tenemos bastante información sobre nuestros usuarios (parte de la funcionalidad es aplicar a los trabajos y enviando su cv con eso)

Pensamos en cifrar / descifrar datos confidenciales con un par de claves privado / público cuya clave privada está cifrada con la contraseña del usuario, pero encontramos algunos problemas de seguridad e implementación con eso: P

la pregunta es ¿cómo implementar la privacidad del usuario y una protección contra el robo de datos en servidores web centralizados con protocolos compatibles con el navegador, mientras que para la funcionalidad se requiere que los usuarios puedan intercambiar datos sensibles?

Para dar una idea adicional: este proyecto aún no está en la etapa de producción, por lo que todavía hay tiempo para hacer las cosas bien.

ya estamos haciendo algunas cosas básicas como

  • sirviendo https
  • hacer cumplir https para sitios que pueden manejar datos confidenciales
  • hashing contraseñas saladas
  • un poco de endurecimiento de nuestro servidor y servicios en él
  • discos duros cifrados para evitar que alguien lea toda la información del cliente después de robar nuestros servidores / discos duros

pero eso es todo, además del hash de contraseña, no hay un mecanismo que pueda detener / al menos dificultar que alguien que logró ingresar (parte de) el servidor obtenga todos los datos de todos nuestros usuarios. Tampoco vemos una manera de encriptar los datos de los usuarios para impedirnos a nosotros mismos leerlos, ya que necesitamos los datos (no los hubiéramos recopilado de otra forma) para alguna parte del sitio web / la funcionalidad que queremos que proporcione. Incluso si, por ejemplo, gestionamos de alguna manera (quizás con algún javascript) todos los datos nos cifraran (por el navegador del cliente) y le entregamos al cliente su clave privada cifrada con alguna contraseña (como por ejemplo su contraseña de inicio de sesión), no podríamos examle scan usuario subió archivos para virus y similares. Por otro lado, un cifrado del lado del cliente al menos con el concepto de navegador / servidor web dejaría algunos problemas con la seguridad al menos como lo imaginamos (le invitamos a demostrar que estoy equivocado) y parece bastante como reinventar la rueda, y tal vez como este proyecto no se trata principalmente de privacidad, sino que la privacidad es una propiedad preferible que no queremos reinventar la rueda para ella. Creo firmemente que no soy el primer desarrollador web que piensa en esto, ¿verdad? Entonces, ¿qué han hecho otros proyectos? ¿Qué has hecho para intentar proteger los datos de tus usuarios?

si es relevante, estamos usando django y postrgreSQL para la mayoría de las cosas y javascript para alguna interfaz de usuario

ps: este artículo  describe algunas otras razones por las que dudamos acerca del cifrado del lado del cliente

    
pregunta Freebejan 13.06.2014 - 10:18
fuente

1 respuesta

4

Un método estándar utilizado para algo como esto es el cifrado de la capa de aplicación.

Su proyecto consiste en un nivel web (Django) y un nivel de base de datos (PostgreSQL). Si implementa su cifrado en Django, puede escribir blobs cifrados en el almacén de datos de PostgreSQL. Esto no es, por cierto, el "cifrado del lado del cliente" como se describe en el artículo al que se vincula.

La ventaja de este método es que separa los datos cifrados de las claves. Un atacante que puede volcar tablas de su base de datos puede obtener los datos cifrados, pero no las claves. Un atacante que pueda comprometer su aplicación y extraer la clave aún necesita obtener los datos para utilizarla.

La desventaja de este método es que los datos cifrados no se pueden buscar ni manipular únicamente en el nivel de la base de datos. Si son contraseñas, eso está bien; No va a SELECCIONAR todas las contraseñas con ciertos criterios, por lo general, solo obtendrá una y la comparará. Pero para otros tipos de datos que pueden ser onerosos.

Actualice para abordar el comentario a continuación con la longitud adecuada:

Sí, si el atacante compromete la aplicación, es posible que comprometan la clave, y posiblemente incluso aprovechen el acceso a la base de datos de la aplicación para aprovechar la clave. Entonces, ¿por qué es esto mejor?

En primer lugar, elimina algunos ataques comunes de toma de contacto de un solo vector. Si la aplicación web sufre de inyección de SQL, por ejemplo, un atacante generalmente puede extraer tablas completas de la base de datos. Pero no pueden extraer la clave de la aplicación de la misma manera, y luego necesitarán otro ataque exitoso por separado para lograr su objetivo.

El atacante puede esperar por algo interesante, pero si comprometen la aplicación, es probable que puedan interceptar las entradas y la información de compromiso antes de que se envíe a la base de datos; el acceso a la clave es irrelevante en ese punto. Y eso requiere un compromiso y paciencia a largo plazo, lo cual es menos preocupante a menos que sea un objetivo en el espacio de APT.

Se pueden establecer controles de compensación para limitar el impacto del compromiso de la capa de aplicación. Por ejemplo, si la aplicación solo tiene acceso a ciertos procedimientos almacenados y no la capacidad de ejecutar SQL arbitrario en la base de datos, entonces incluso si el atacante compromete la aplicación y obtiene la clave, es posible que no pueda aprovecharla para obtener datos en masa. . Cualquier iteración para obtener datos por partes es mucho más probable que quede atrapada por el registro, las alertas o las herramientas de monitoreo de SQL.

Y, aunque es menos común, el almacenamiento separado de la clave previene los ataques de respaldo que obtienen acceso a los archivos de respaldo de la base de datos.

No hay seguridad perfecta, pero la defensa en profundidad es un método comprobado para mejorar la seguridad. Separar la clave de cifrado de los datos cifrados en una aplicación de múltiples niveles es una excelente contribución para la defensa en profundidad.

    
respondido por el gowenfawr 13.06.2014 - 15:08
fuente

Lea otras preguntas en las etiquetas