Cifrado y protección de datos de mí mismo (y piratas informáticos)!

Question

Cifrado y protección de datos de mí mismo (y piratas informáticos)!

#1 de guest (2 votos)

4

Estoy tratando de descubrir una estrategia de cifrado decente para una aplicación de pequeña empresa. Mi objetivo principal es exponerme a la menor cantidad de PI sin cifrar que sea posible.

No tengo idea de si estoy pensando demasiado en esto y hay una manera fácil, así que pensé en preguntar. También me gustaría saber si alguno de mis pensamientos es una completa basura.

He pensado en 2 estrategias hasta ahora:

Cuando un usuario inicia sesión, se le solicita que ingrese una contraseña de descifrado principal. Esta contraseña se utiliza para descifrar la clave privada y se genera una cadena aleatoria & almacenado en una cookie (o tal vez en almacenamiento local + transmitido con cada solicitud de publicación). La clave privada se vuelve a cifrar con la cadena aleatoria y cada vez que se solicitan datos cifrados, la cadena de la cookie se utiliza para descifrar la clave, luego los datos.
- Desventaja: como administrador / pirata informático del servidor, obviamente podría interceptar la contraseña maestra y descifrar la clave, luego los datos.
- Ventaja: bastante sencillo.
La clave pública solo se almacena en el servidor. Entre el servidor y el cliente hay un proxy inverso que analiza el contenido (similar a cómo funciona ESI). Este servidor proxy contendría la clave privada y descifraría los datos antes de servir al cliente. Las claves en este servidor no serían administradas por el mismo administrador.
- Desventaja: como administrador / hacker proxy, obviamente, podría interceptar los datos a medida que pasan. También tendría acceso a la clave privada.
- Ventaja: como administrador / pirata informático proxy, no tendría credenciales para la aplicación, por lo tanto, solo podrá rastrear los datos solicitados por los usuarios finales.
- Ventaja: en un entorno empresarial, es probable que este servidor se pueda proteger mucho más fácilmente contra fuentes externas. No se permiten conexiones entrantes en absoluto.

Lo siguiente se trata como un hecho:

Todo el transporte está protegido por SSL.
En todos los escenarios, tendría acceso a los datos tal como fueron ingresados. Esto podría mitigarse utilizando el cifrado de clave pública JS.
La autenticación real de la aplicación es apta para el propósito. ES DECIR. La ingeniería social, la fuerza bruta, etc. están descontadas. Los problemas / errores basados en el navegador no se descuentan.
Un equipo de personas autorizadas debe poder acceder a los datos cifrados.
Se debe acceder a través de un navegador.
Todo el disco está cifrado en reposo, lo que no es un beneficio para, por ejemplo, romper la raíz a través de SSH.

He descontado lo siguiente:

Descifrado JS: por lo que he visto, esto simplemente significa que la clave privada está expuesta al usuario final.
teclas simétricas & claves de pub / priv sin cifrar en el servidor, DB en otro servidor. No estoy realmente seguro del valor de estos. Como administrador o pirata informático, tendría todo lo que necesito para descifrar los datos de MySQL si incurriera en una infracción del servidor de aplicaciones.
Servidores clave de terceros: esto parece pasarle la pelota a otra persona que pueda ver el contenido (aunque me pregunto si hay un proceso de varios pasos que podría funcionar en conjunto).

encryption

pregunta user164613 26.11.2017 - 03:12

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption

¿Qué función desempeñan los cifrados de hash y de bloque en la generación de números aleatorios? Cómo crear de forma segura un "usuario honeypot (linux)"

score 2 · Answer 1

Las soluciones que sugiere pueden romperse, dado que solo mueven la confianza a otro lugar. Necesita una solución criptográfica que garantice lo siguiente:

Su servidor puede aceptar y transmitir material cifrado a los usuarios correctos.
El usuario tiene acceso a la clave de cifrado.
El servidor no tiene acceso a la clave de cifrado.

Esto requiere criptografía de JavaScript en el navegador, o un programa separado del lado del cliente. Obviamente, existe la posibilidad de que un administrador malintencionado reemplace JavaScript con una versión que envíe la clave o el texto sin formato original al servidor, pero esto siempre será un riesgo.

Dependiendo del tipo de datos que se almacenan, ya existe una solución bastante simple utilizada por muchos sitios web de pegado como Zerobin y 0bin, así como el popular host de archivos Mega: cifrado del lado del cliente . JavaScript en el navegador crea una clave de cifrado simétrica y la agrega como el fragmento (cualquier cosa más allá del octotorpe) de la URL. El fragmento solo es visible para el navegador, no para el servidor. JavaScript en el navegador encripta los datos utilizando este fragmento y carga los datos en el servidor. El resultado es que necesita la URL completa para poder ver la página, y el servidor no puede descifrar.

Por lo tanto, una URL se puede representar como example.com/path#fragment . Su ISP ve example.com , ya que esto es lo que envía al servidor DNS. Incluso con el uso de TLS, el dominio aún se envía de forma clara como resultado de SNI. /path solo es visible para el servidor al que lo está enviando, asumiendo que está usando TLS. Esto es lo que el servidor usa para determinar qué enviar al cliente. La última parte, #fragment , solo está visible para su navegador.

Toma esta URL de ejemplo de Zerobin:

zerobin.net/?5cd884d7e1409f31#25LMCTnmrN3H/BPcebRjH6Gl05Sklj91CssV45YwQ/o=
|   host  |    identifier    |            base64 encoded key              |

En este ejemplo, el dominio es, obviamente, la dirección del servidor. El identificador es la ruta que especifica qué pegado encriptado se solicita. Cuando se recupera la página, el fragmento nunca se envía al servidor. Cuando se busca un archivo, todo lo que el servidor ve es esto (en este ejemplo, usar cURL en lugar de un navegador web):

GET /?5cd884d7e1409f31 HTTP/1.1
Host: zerobin.net
User-Agent: curl/7.56.1
Accept: */*

Esto le indica al servidor que recupere la publicación cifrada y la sirva, junto con el JavaScript necesario para descifrarlo. Si la clave no es correcta, o la clave no está presente, el código de la página no podrá descifrarla. El objetivo es garantizar que el texto en claro solo sea visible para alguien que tenga la URL. Depende de ellos decidir si la URL se debe distribuir ampliamente o si se debe mantener relativamente secreta. Esta técnica podría modificarse fácilmente para usar una contraseña en lugar de un fragmento de URL, pero si el problema es simplemente reducir el PI, debería ser suficiente.

Más información sobre esta información específica en la página del proyecto Zerobin .

Con suficiente ingeniería, esto se puede hacer para almacenar mucho más que simplemente pegar texto. Mega, por ejemplo, admite el acceso al almacenamiento como un sistema de archivos. Incluso hay una utilidad que monta su directorio de usuarios en línea como un sistema de archivos utilizando FUSE, que permite la interacción utilizando acciones genéricas del sistema de archivos, y al mismo tiempo garantiza que el servidor no sepa a qué se accede. Se podría hacer su solicitud para hacer esto si se ajusta a sus requisitos.