Historias
Slashboxes
Comentarios
 

Privacidad obsesiva

Entrada escrita por granda y editada por nettizen el Jueves, 20 Agosto de 2015, 00:00h   Printer-friendly   Email story
Uno de mis proyectos personales es un gestor de entrenamientos (correr, bicicleta, natación, etc.). Es un proyecto LAMP sencillo nacido porque quería tener un mayor control de los datos que mis actividades deportivas generan. Llevo un tiempo pensando en darle un punto más de privacidad y sería la de cifrar los datos almacenados en el servidor en forma de ficheros xml que producen los relojes deportivos supervitaminados con recepción de señal GPS para evitar que puedan ser leídos por alguien que ganase acceso de manera ilegítima al servidor. Dichos ficheros son enviados desde el ordenador del usuario al servidor usando un canal seguro (https) y posteriormente el servidor debe ser capaz de leerlos y procesarlos (acceso lectura).
La primera opción que se me pasó por la cabeza fue usar GPG, pero como mi proyecto es un servicio que también usan otras personas menos familiarizadas (y posiblemente menos cuidadosas con la vigilancia de la clave privada) con un sistema de clave pública/privada, lo he descartado. Luego me fijé en Mega. Por lo visto había desarrollado un sistema de cifrado interesante, pero habría que adaptarlo porque yo necesito que el servidor sí tenga acceso a los ficheros, ya sea pidiendo una contraseña al usuario o (preferiblemente) de manera automática cuando el usuario está correctamente acreditado (vía cookie por ejemplo). Y por último he visto OwnCloud, con un modelo de cifrado interesante y que podría cuadrar bien. Después del desafío técnico y obviando razones de eficiencia en la ejecución, comprendo que hay (al menos) dos situaciones donde un atacante podría tener acceso a los datos cifrados:

1.- Se dedica a inspeccionar el tráfico usando la clave privada del certificado SSL/TLS que está en el servidor.

2.- Inspecciona memoria y/o directorios temporales donde estén los datos temporalmente en claro.

Así que: ¿tiene alguien experiencia al respecto?, ¿alguna recomendación?. ¡Gracias!

Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Mi no entender

    (Puntos:1, Informativo)
    por pobrecito hablador el Miércoles, 19 Agosto de 2015, 19:19h (#1371633)

    Llevo un tiempo pensando en [...] cifrar los datos almacenados en el servidor [...] para evitar que puedan ser leídos por alguien que ganase acceso de manera ilegítima al servidor [...] el servidor debe ser capaz de leerlos y procesarlos
    No es posible. Si de verdad, _de_verdad_ quieres que aunque un juaker maligno gane acceso root a tu servidor no sea capaz de conocer el contenido de los ficheros, los ficheros tienen que salir ya cifrados desde el cliente. El cifrado/descifrado debe realizarse en el cliente; el tratamiento de datos, la generación de gráficas con históricos y tal deben realizarse en el cliente. El servidor sólo actuaría como almacén tonto de datos cifrados.

    Lo que necesitas buscar en Google es "client side data encryption".

    [ Responder ]
  • Paranoia excesiva

    (Puntos:1, Interesante)
    por pobrecito hablador el Viernes, 21 Agosto de 2015, 08:03h (#1371662)

    Si se trata de un ejercicio intelectual, vale. Si se trata de proteger la privacidad aún más de lo que tienes ahora con https, creo que es complicarte la vida inútilmente, multiplicar el trabajo y la complejidad por 100 para obtener un incremento de la seguridad del 0.00001%

    ¿Vale la pena?

    Frenar a un atacante ha tenido acceso a tu servidor y puede leer temporales, es ya seguridad de alto nivel. Para empezar, puede modificar los scripts e introducir exploits. Así que lo primero es que cambies el lenguaje interpretado por un compilado y/o un cron que periódicamente saque el MD5 y SHA de los programas y alerte si se han modificado.

    Yo me preocuparía más y dedicaría más recursos a asegurarme de que tu código no tiene bugs o problemas de seguridad.

    Además, la seguridad no es sólo un programa, sino una serie políticas. Si implicas a usuarios sin conocimientos y poco dispuestos a perder el tiempo, todo se vuelve complicado.

    Teniendo en cuenta que seguramente usas un hosting y no eres el único que tiene acceso root, la única opción es que los datos se cifren en la parte del cliente, y que el servidor funcione a ciegas. Aún así, el atacante, si tiene acceso root, como he dicho, puede cambiar los scripts, javscript etc, que recibe el cliente para cifrar.

    La otra opción es la que propones, cifrar los datos con la contraseña que te pasa el cliente, no vale porque si el atacante es root, tiene acceso a la clave privada del certificado y puede descifrar las comunicaciones, podría interceptar la.

    Sin embargo, esta última opción es aceptable si lo que pretendes es sólo frenar a alguien que NO haya conseguido escalar a root, por ejemplo tenga acceso de lectura a los archivos.

    ¿Vale la pena la complicación de manejar datos cifrados por tan poca mejora?

    [ Responder ]
  • Fe de erratas

    (Puntos:1)
    por morgano (4518) el Jueves, 20 Agosto de 2015, 00:34h (#1371642)
    ( Última bitácora: Martes, 25 Agosto de 2015, 03:22h )
    Donde dije Netizzen quise escribir Nettizen, perdón por la cagada
  • por granda (2039) el Jueves, 20 Agosto de 2015, 16:55h (#1371656)
    ( http://blog.deif.org/ | Última bitácora: Miércoles, 19 Agosto de 2015, 16:06h )
    Parece interesante, pero como bien comentas parece más encaminado a tener máquinas con relaciones de confianza establecidas y no cualquier cliente con un servidor, ¿no?.

    El asunto es que las acciones son bajo demanda del usuario y no veo claro que el servidor esté en un bucle infinito preguntando... ¿WebSockets [mozilla.org]?)
    --
    FortSu.es [fortsu.es] - El buscador de zapatillas
  • 2 respuestas por debajo de tu umbral de lectura actual.