WebCrypto
Las preocupaciones con la criptografía en JavaScript del lado del cliente (navegador) se detallan a continuación. Todas menos una de estas preocupaciones no se aplican a la API de WebCrypto , que ahora es razonablemente compatible .
Para una aplicación sin conexión, aún debe diseñar e implementar un almacén de claves seguro.
Aparte: si está utilizando Node.js, use la API de cifrado incorporada .
Criptografía Native-Javascript (pre-WebCrypto)
Supongo que la principal preocupación es alguien con acceso físico a la computadora que lee localStorage
su sitio y desea criptografía para evitar ese acceso.
Si alguien tiene acceso físico, también está abierto a otros ataques y algo peor que leer. Estos incluyen (pero no se limitan a): registradores de teclas, modificación de script fuera de línea, inyección de script local, envenenamiento de caché del navegador y redireccionamientos de DNS. Esos ataques solo funcionan si el usuario usa la máquina después de haber sido comprometida. Sin embargo, el acceso físico en tal escenario significa que tiene mayores problemas.
Tenga en cuenta que el escenario limitado en el que la criptografía local es valiosa sería si se roba la máquina.
Hay bibliotecas que implementan la funcionalidad deseada, por ejemplo, Stanford Javascript Crypto Library . Sin embargo, hay debilidades inherentes (como se menciona en el enlace de la respuesta de @ ircmaxell):
- Falta de entropía / generación de números aleatorios;
- La falta de un almacén de claves seguro, es decir, la clave privada debe estar protegida con contraseña si se almacena localmente o en el servidor (que impide el acceso sin conexión);
- Falta de borrado seguro;
- Falta de características de tiempo.
Cada una de estas debilidades corresponde a una categoría de compromiso criptográfico. En otras palabras, si bien puede tener "cripto" por nombre, estará muy por debajo del rigor al que uno aspira en la práctica.
Dicho todo esto, la evaluación actuarial no es tan trivial como "Javascript crypto es débil, no lo use". Esto no es un endoso, estrictamente una advertencia y requiere que comprenda completamente la exposición de las debilidades anteriores, la frecuencia y el costo de los vectores que enfrenta, y su capacidad de mitigación o seguro en caso de falla: Javascript crypto, en a pesar de sus debilidades, puede reducir su exposición, pero solo contra ladrones con capacidad técnica limitada. Sin embargo, debe suponer que la criptografía Javascript no tiene valor contra un atacante determinado y capaz que se dirige a esa información. Algunos considerarían engañoso llamar a los datos "encriptados" cuando se sabe que hay tantas debilidades inherentes a la implementación. En otras palabras, puede disminuir marginalmente su exposición técnica, pero aumenta su exposición financiera de la divulgación. Cada situación es diferente, por supuesto, y el análisis para reducir la exposición técnica a la exposición financiera no es trivial. Aquí hay una analogía ilustrativa:Algunos bancos requieren contraseñas débiles , a pesar del riesgo inherente, porque su exposición a pérdidas por contraseñas débiles es menor que los costos para el usuario final de soportar contraseñas seguras.
🔥 Si leyó el último párrafo y pensó "Un tipo en Internet llamado Brian dice que puedo usar Javascript crypto", no use Javascript crypto.
Para el caso de uso descrito en la pregunta, parece tener más sentido que los usuarios cifren su partición local o directorio de inicio y usen una contraseña segura. Ese tipo de seguridad es generalmente bien probado, ampliamente confiable y comúnmente disponible.