Problemas con en Crypto del navegador

7

Hay muchos artículos antiguos 1 sobre por qué el criptográfico en el navegador es una mala idea. La mayoría se resumen en: enlace

  

Creemos que SJCL proporciona la mejor seguridad que está prácticamente disponible en Javascript. (Desafortunadamente [sic], esto no es tan bueno como en las aplicaciones de escritorio porque no es posible proteger completamente contra la inyección de código, servidores maliciosos y ataques de canales laterales).

Parece que el mayor problema que mencionan es que un atacante podría tener un mal javascript que el navegador ejecuta porque XSS es muy común.

Entre TLS y una Política de seguridad de contenido extremadamente restrictiva, ¿sigue siendo esto un problema y, por lo tanto, una mala idea para el cifrado en el navegador?

El objetivo del cifrado no es reemplazar TLS. Se utiliza para cifrar documentos antes de que lleguen al servidor, de modo que solo el remitente y el destinatario puedan leerlos.

1:

pregunta erik 08.08.2016 - 19:11
fuente

1 respuesta

11

He estado esperando que alguien preguntara sobre este tema, he estado investigando mucho en el área.

Usted tiene razón en que la mayoría de los puntos en javascript-criptografía-considerada-dañina están pasados de moda por los navegadores más nuevos. Aparte del problema obvio de alguien que compromete el servidor, que es un problema aparte y también presenta un problema para TLS, los puntos principales ahora están "solucionados":

  • window.crypto.getRandomValues() usa un CSPRNG real
  • HTTPS es común y mucho más barato ahora que en 2011
  • Los atributos integrity y nonce <script> de CSP pueden asegurar la entrega de scripts para asegurarse de que se espere lo que se está ejecutando
  • SJCL es un año más maduro que en 2011, y no hay problemas importantes pendientes
  • los tiempos de ejecución maleables no importan si no tiene XSS, qué CSP ahora son buenos para detener

Además, ahora sabemos que HTTPS no es una garantía absoluta de privacidad (snowden / heartbleed / crime / breach / etc), pero sí lo es el cifrado de extremo a extremo. Ahora también podemos implementar bibliotecas bastante robustas, probadas en la batalla y seguras, respaldadas por un tiempo de ejecución JS más seguro que el que se ofreció en 2011; "use strict" ampliamente soportado, un CSPRNG, estructuras binarias, trabajadores web con entornos de ejecución sellados, etc.

Esas son actualizaciones de los puntos principales, pero si le preocupan otros aspectos de la criptografía del cliente, estaré encantado de atenderlos.

Por supuesto, nada es perfecto:

  • los navegadores realmente antiguos todavía tienen problemas o no pueden ejecutar un nuevo código de forma segura
  • las extensiones agregadas por el usuario pueden ejecutar el código que quieran
  • el malware puede reemplazar todo el navegador con algo siniestro, o puede robar el cifrado previo de los datos
  • el phishing puede engañar al usuario para que use algo que no sea su sitio seguro.

En pocas palabras, creo que después de Snowden, deberíamos tratar de mantener los datos privados simples fuera de los servidores donde sea que podamos ayudarlos, y el sólido encriptado de extremo a extremo, hecho correctamente, mejora enormemente la la privacidad de sus usuarios y la seguridad de su contenido.

    
respondido por el dandavis 08.08.2016 - 20:55
fuente

Lea otras preguntas en las etiquetas