Cifrado de archivos en Javascript antes de enviarlos a Google Storage

Question

Cifrado de archivos en Javascript antes de enviarlos a Google Storage

#1 de AndrolGenhald (1 votos)
#2 de iainpb (1 votos)
#3 de McMatty (0 votos)

1

Estoy buscando permitir que los usuarios de nuestro sitio web carguen sus archivos directamente en el almacenamiento de GCE sin enviar el archivo a nuestro servidor.

Pero queremos que el archivo se cifre primero antes de guardarlo en GCE. El cliente no necesita acceso al archivo ni a la clave de cifrado que generó una vez que se realiza con la carga.

Por lo tanto, en lo que estoy pensando es:

el cliente (javascript que se ejecuta en el navegador) genera una clave simétrica aleatoria, cifra el archivo y lo carga a GCE
el cliente envía la clave al servidor y la destruye

Comunicación entre cliente y amp; los servidores están, por supuesto, a través de https.

Preguntas:

¿Es seguro este enfoque? Si no, ¿por qué?
¿Sería mejor usar un cifrado híbrido? Usar una clave pública para cifrar la clave simétrica recién generada antes de enviarla al servidor. Si es así, ¿cuál es el beneficio?

Corríjame si estoy equivocado, pero preferiría evitar solo el uso de cifrado asimétrico, ya que podemos cifrar archivos bastante grandes y creo que el cifrado asimétrico no funciona bien en ese caso.

Gracias

cryptography encryption

pregunta Marc Simon 02.03.2018 - 15:10

fuente

3 respuestas

1

En primer lugar, me gustaría proponer una edición para su pregunta.

"El cliente NO tendrá acceso al archivo una vez que se haya cargado ".

a

"The client SHOULD not have access to the file once it is done uploading it."

Siempre debe considerar que un actor malintencionado podría recuperar sus datos del almacenamiento y considerar si sus activos están protegidos adecuadamente si eso sucede.

Las consideraciones aquí son que nunca debe exponer una clave de cifrado a nadie a quien no desea que tenga acceso a los datos.

Debe considerar qué tan seguro y aleatorio es su generador de claves aleatorias, que cualquier persona con acceso al javascript puede ver cómo funciona y podría predecir claves y también que luego está enviando esta clave al servidor, lo que podría ser visible para ciertos ataques MITM.

En este caso, es mucho mejor que esté utilizando el cifrado asimétrico, el cifrado en el lado del cliente con la clave pública y permitiendo el descifrado solo con su clave privada del scret

respondido por el iainpb 02.03.2018 - 15:37

fuente

0

No, si está cifrando un archivo y enviándolo a través de TLS no está obteniendo nada aquí.

Al cifrar con una clave simétrica que envía con el archivo, básicamente está enviando una caja de seguridad con la clave grabada.

También confiar en el cliente está transfiriendo la responsabilidad de la seguridad de usted a sus usuarios. ¿Están parcheados sus navegadores? ¿Tienen instaladas extensiones de navegador que puedan ser comprometidas? ¿Existe una vulnerabilidad de XSS en su sitio que permita que el navegador se enganche?

Si hay un requisito para que estos archivos estén encriptados, maneja eso en su servidor y no en el navegador. Si no tiene el requisito de que los archivos estén cifrados en la nube con una clave, no toque el cifrado, solo asegúrese de que las conexiones sean TLS 1.2

respondido por el McMatty 03.03.2018 - 02:30

fuente

Lea otras preguntas en las etiquetas cryptography encryption

¿Cómo verificar si un archivo de imagen está limpio? Veracrypt - Partición USB cifrada - ¿Pasa la clave por USB?

score 1 · Accepted Answer

Entonces está cifrando un archivo para cargarlo a un servicio de terceros, y luego envía la clave a su propio servidor. Echemos un vistazo a las opciones propuestas para enviar la clave:

Envíalo por TLS
Cifrelo con la clave pública de su servidor, luego envíelo a través de TLS

Entonces, lo que quieres saber es si la opción 2 es mejor que la opción 1.

¿Se puede omitir TLS?

Si un atacante no puede pasar TLS, entonces ambas opciones están bien, así que supongamos que pueden (por ejemplo, sslstrip, usar ingeniería social para que confíe en su certificado TLS, etc.). Si el atacante puede pasar TLS, apesta . Cuánto apesta depende del tipo de atacante.

atacante pasivo

Si un atacante pasivo puede leer su tráfico TLS, ha socavado la confidencialidad, pero no puede alterar el tráfico de ninguna manera. En este caso, el uso del cifrado asimétrico para cifrar la clave del archivo antes de enviarlo a su servidor lo protegería.

atacante activo

Un atacante activo puede leer su tráfico, pero también puede modificarlo . En este caso, tienes una manguera. Simplemente pueden modificar el JavaScript para que el cliente cargue el archivo en su propio servidor antes de encriptarlo, y quizás aún lo cifre y lo cargue en el servicio de terceros para que nadie se dé cuenta de algo incorrecto.

¿Cuál es más probable?

Si alguien está en posición de leer su tráfico TLS, debe tener la clave privada de su certificado (que es muy mal), o han interceptado la intercambio de claves, lo que significa que probablemente sean un atacante activo.

¿Hay una mejor opción?

Si le preocupa la seguridad de su conexión TLS, las soluciones son HPKP y HSTS ( aunque tenga cuidado de advertencias ).

Conclusión

En un contexto web, intentar usar JavaScript para mejorar la seguridad de su conexión está generalmente condenado al fracaso. Haga todo lo que pueda para asegurarse de que su conexión TLS sea segura y solo use eso.