javascript react ¿Cuáles son los casos de uso válidos para el cifrado del lado del cliente?



rsa javascript github (3)

Un uso que viene a la mente es a prueba de host. Aquí es donde desea almacenar los datos en el servidor o almacenar y reenviar a través del servidor, pero no le da acceso al servidor a los datos.

El cliente puede encriptar los datos antes de la transmisión al servidor y mantener la clave privada o al menos la contraseña de la clave privada localmente.

Creo que esta es la base de servicios como el último paso .

Acabo de leer sobre Stanford JavaScript Crypto Library ( ejemplo de jsfiddle ) que admite SHA256, AES y otros esquemas de cifrado estándar en javascript. La biblioteca parece muy ingeniosa, pero no sé de un caso de uso razonable para ella.

Como ya han señalado algunas preguntas , el cifrado del lado del cliente no es una forma segura de pasar datos seguros a un servidor. HTTPS debería usarse en su lugar. Entonces, ¿hay algún proyecto que se beneficie o requiera el cifrado del lado del cliente?


Utilice el caso 1

¿Qué hay de almacenamiento local ? Es posible que desee almacenar algunos datos, pero encriptarlos para que otros usuarios de la computadora no puedan acceder a ellos.

Por ejemplo:

  • El usuario se conecta al servidor a través de HTTPS.
  • El servidor autentica al usuario.
  • El servidor sirve una contraseña de cifrado específica para este usuario.
  • El usuario hace algunas cosas localmente.
  • Algunos datos se almacenan localmente (cifrados con la contraseña).
  • El usuario se va
  • El usuario vuelve al sitio en una etapa posterior.
  • El usuario se conecta a través de HTTPS.
  • El servidor autentica al usuario.
  • El servidor sirve la contraseña de encriptación del usuario.
  • El lado del cliente JS usa una contraseña de cifrado para descifrar datos locales.
  • El usuario hace algo u otro localmente con sus datos locales en memoria ahora descifrados.

Esto podría ser útil en casos en los que tenga un cliente avanzado, con muchos datos (confidenciales) que se deben usar en todas las sesiones, donde el servicio del servidor no es factible debido al tamaño. No puedo pensar en tantos ejemplos en los que esto se aplicaría ...

También podría ser útil en casos donde el usuario de la aplicación genera datos confidenciales y que los datos no necesitan (o no deben) enviarse (o almacenarse) en el servidor.

Para un ejemplo aplicado, puede almacenar localmente los detalles de la tarjeta de crédito del usuario, encriptarlos y usar JS para ingresarlos automáticamente en un formulario. Podrías haber hecho esto guardando el lado del servidor de datos, y sirviendo una forma pre-poblada de esa manera, pero con este enfoque no tienes que almacenar los detalles de tu tarjeta de crédito en el servidor (que en algunos países, hay estrictos leyes sobre). Obviamente, es discutible si almacenar datos de la tarjeta de crédito encriptados en la máquina del usuario es más o menos un riesgo de seguridad que almacenarlo en el servidor.

Probablemente haya un mejor ejemplo aplicado ...

No conozco ningún proyecto existente que use esta técnica.

Utilice el caso 2

¿Qué hay de las mejoras de rendimiento a través de HTTPS, facilitadas mediante el uso compartido de contraseñas?

Por ejemplo:

  • El usuario se conecta al servidor a través de HTTPS.
  • El servidor autentica al usuario.
  • El servidor sirve una contraseña de cifrado específica para este usuario.
  • El servidor luego redirecciona a HTTP (que tiene una sobrecarga mucho menor que HTTPS, por lo que será mucho mejor en términos de rendimiento).
  • Como tanto el servidor como el cliente tienen la contraseña de cifrado (y esa contraseña se compartió a través de una conexión segura), ahora pueden enviar y recibir datos confidenciales encriptados de manera segura, sin la sobrecarga de cifrar / descifrar solicitudes completas con HTTPS. Esto significa que el servidor podría servir una página web donde solo se encriptan las partes sensibles de la misma. El cliente podría descifrar las partes encriptadas.

Este caso de uso probablemente no valga la pena, ya que HTTPS generalmente tiene niveles de rendimiento aceptables, pero sería útil si necesita exprimir un poco más de velocidad.

Utilice el caso 3

Almacenamiento a prueba de host . Puede encriptar el lado del cliente de datos y luego enviarlo al servidor. El servidor puede almacenar los datos y compartirlos, pero sin conocer la clave privada del cliente, no puede descifrarlos. Se cree que esto es la base de servicios como el último paso .


Al igual que cualquier cosa en el cliente, puede usar la ofuscación para hacer las cosas más difíciles para los usuarios casuales, pero dado que el cliente también necesitaría tener una copia del descifrador, tampoco hay nada que impida que el usuario use el descifrador.

JavaScript es un entorno inseguro, punto.





client-side