¿El cifrado del lado del navegador es realmente seguro?

0

Tengo una aplicación web que espero escribir donde se comprime y encripta una selección de archivos en el navegador antes de subirlos a mi servidor. Tengo un prototipo del sistema y está funcionando muy bien. Quiero hacerlo en el navegador sin la participación del servidor cuando se manejan los archivos no cifrados por motivos de privacidad.

El proceso general es:

  1. El usuario selecciona archivos locales en su computadora
  2. Comprime esos archivos juntos
  3. generar una clave
  4. Encripta el zip con la clave
  5. Cargue el zip cifrado en el servidor (este es verificadamente el primer uso de la red después de cargar la página)

Mi objetivo es saber lo menos posible sobre el paquete cargado. Zipping significa que no sé cuántos archivos hay y porque las claves son todas del lado del cliente administrado, no hay absolutamente ninguna manera de poder descifrar el paquete. Mi servicio tiene que ver con el almacenamiento, por lo que nunca necesito transmitir la clave a ningún lugar. La clave está disponible para que el usuario la administre personalmente.

Me doy cuenta de que el uso de la seguridad de javascript permite a mis clientes manipular los valores para invalidar la seguridad, pero como solo son capaces de modificar el código que los afecta, un usuario solo puede debilitar la seguridad de los paquetes que cargan. Supongo que un usuario que se esfuerce por dispararse en el pie no es un problema que deba intentar evitar.

MITM parece una posibilidad. Eve podría manipular los archivos JS solicitados para eliminar el cifrado y Eve podría recuperar un paquete no cifrado durante la carga, pero no creo que esto presente ningún problema nuevo en un sistema donde el paquete se envía a mi servidor y luego se cifra. HTTPS y un usuario bien educado pueden ayudar a evitar que un MITM también tenga éxito. "Usuario bien educado" puede ser un sueño imposible, pero puedo hacer mi parte para intentar educar a mis usuarios antes de que comience el proceso.

El último y hasta ahora peor problema que se me viene a la mente es la posibilidad de una extensión de navegador malintencionada. Podría manipular el JS para eliminar el cifrado, pero la carga aún sería segura utilizando una conexión HTTPS forzada (el servidor puede rechazar las cargas no seguras). Desde que leí en archivos usando la API FileReader de Javascript, una extensión maliciosa podría interceptar el blob sin cifrar y cargarlo a un tercero. ¿Cómo podría defenderme de algo así? Sé que mi sitio y los servidores no han sido violados, pero esto sigue siendo una gran pérdida para mis clientes. ¿Se puede hacer algo al respecto?

Si la conexión con el servidor es 100% HTTPS, ¿qué tipo de ataques podrían dirigirse a un sistema como este? ¿Hay problemas en los que no haya pensado que debo prepararme? ¿Qué puedo hacer para garantizar la seguridad y la privacidad?

    
pregunta Corey Ogburn 12.06.2015 - 17:48
fuente

2 respuestas

1

Lo que está proponiendo es la misma arquitectura que se usa en los administradores de contraseñas en línea como Lastpass y las carteras de Bitcoin en línea como Blockchain . Usted ha llamado a las dos grandes amenazas: manipulación de Javascript y una computadora comprometida.

Para hacer frente a la amenaza de manipulación de Javascript, asegure el servidor y convenza a los usuarios de que su Javascript es seguro.

Con respecto a las extensiones de navegador maliciosas u otros códigos maliciosos en la computadora, no puedes hacer mucho al respecto. Debe dejarlo en manos de sus usuarios para garantizar que su computadora esté segura.

    
respondido por el Neil Smithline 12.06.2015 - 19:11
fuente
1

Confiar en el servidor es inevitable, y tienes que confiar en el servidor de todos modos si el cifrado se basa en el servidor. Los ataques MITM también se aplican a criptografía basada en servidor, y no veo ninguna razón por la que un complemento malintencionado tampoco pueda atacar criptografía basada en servidor.

La principal diferencia es que confías en el extremo del cliente para realizar el cifrado, donde tienes menos control del entorno de programación. Una cosa que debes tener en cuenta es la generación de números aleatorios utilizados en Javascript. Math.random () es lo que muchas personas pueden usar como fuente de números aleatorios, pero no es apropiado para el uso de criptografía. Si no está produciendo suficiente entropía para la generación de números aleatorios, podría ser fácilmente vulnerable a los ataques de fuerza bruta en las teclas. Vea esta respuesta para obtener una mejor biblioteca con fines criptográficos .

    
respondido por el Steve Sether 12.06.2015 - 20:50
fuente

Lea otras preguntas en las etiquetas