Cifrado del lado del cliente - solo navegador web disponible

7

Estoy creando una aplicación empresarial, el lado del servidor ejecuta un conjunto completo de aplicaciones diferentes. En el lado del cliente, solo hay una página web, ningún applet o cualquier otra cosa. Desafortunadamente, los datos creados por el usuario pueden ser confidenciales, por lo que debo cifrarlos de alguna manera.

Por lo que entendí, la criptografía de JavaScript no es una buena idea. ¿Qué hay de generar la clave en un servidor de terceros y enviarla al cliente? Se siente como simplemente mover el problema a otro lugar, no arreglarlo.

¿Podrías darme algunos consejos? Realmente no veo cómo cifrar los datos.

    
pregunta Anewbis 12.06.2015 - 10:11
fuente

4 respuestas

3

SSL / TLS es la capa de cifrado entre el navegador y el servidor. Siempre que haya configurado correctamente su SSL / TLS en el servidor, cualquier cifrado de tipo javascript adicional es redundante.

Si está intentando crear una aplicación segura, y su equipo no entiende lo que hace SSL / TLS, puede considerar contratar a un asesor de seguridad para que lo ayude con estos detalles arquitectónicos y asegúrese de evitar cualquier trampa. .

    
respondido por el Byron Jones 12.06.2015 - 22:53
fuente
14
  

La criptografía de JavaScript no es una buena idea

La criptografía de JavaScript no es mala en sí misma, es simplemente ineficaz contra las amenazas consideradas con mayor frecuencia.

Si considera que un hombre en el medio (MITM) es una amenaza, SSL / TLS es un control mucho más efectivo, ya que de lo contrario, el atacante podría sustituir el JavaScript por una versión que no usa cifrado. / p>

Si considera que el software malicioso en el lado del cliente es una amenaza, es probable que pueda modificar el JavaScript de cualquier forma que le guste y su cifrado sería inútil.

Si considera que el lado del servidor es una amenaza (por ejemplo, el cliente quiere que el servidor almacene algo pero no vea el contenido), entonces puede ser efectivo, pero el cliente necesita alguna otra forma de garantizar que JavaScript no lo haya hecho. ha sido manipulado (lo que no es un problema fácil de resolver) y el cliente necesita administrar la clave ellos mismos.

En el caso de uso que has descrito, no parece que el cifrado del lado del cliente realmente agregue seguridad adicional. De cualquier manera, tiene que lidiar con el problema de comunicar la clave, que probablemente dependerá de la integridad de SSL / TLS independientemente . O bien el cliente tendrá que enviar la clave al servidor o al revés, e incluso si usa el cifrado de clave pública para solucionar este problema, tendrá el problema de asegurarse de que la clave pública enviada al cliente sea auténtica. Lo más probable es que termine de reimplementar una infraestructura típica de clave pública.

Dejando eso de lado, no hay un problema fundamental con la realización de la criptografía en JavaScript, excepto que:

  • Por lo general, es bastante lento para la mayoría de los estándares
  • La generación de claves seguras criptográficamente puede ser un problema, especialmente en los navegadores más antiguos que no admiten ciertas API más nuevas para esta tarea
respondido por el thexacre 12.06.2015 - 11:08
fuente
2

¿Piensas usar SSL / TLS en el lado del servidor? Así que los datos atravesarán el canal seguro. Y luego, en el lado del servidor, puede cifrar ti y almacenarlo de tal forma en la base de datos

    
respondido por el Romeo Ninov 12.06.2015 - 10:21
fuente
1

A partir de los comentarios del OP, no parece que esto sea útil para ellos, sin embargo, puede ser útil para otros.

Es posible cifrar de manera útil el lado del cliente de información, pero los casos de uso son pocos y distantes entre sí.

Ejemplo de caso de uso:

  1. El usuario debe trabajar en documentos confidenciales (al menos según su criterio) que deben almacenarse localmente (quizás para reducir los costos del servidor)
  2. La computadora en la que trabajan no está protegida (lo suficiente) de otros usuarios (es decir, alguien más puede abrir su navegador)
  3. Sin embargo, está lo suficientemente seguro como para que los otros usuarios no puedan manipular el sistema operativo, el navegador web o el hardware. (suena descabellado pero tal vez algo como una máquina de quiosco compartida que se haya asegurado físicamente)
  4. El usuario está dispuesto a ingresar una contraseña cada vez que comienza su trabajo.

En este caso, la aplicación javascript podría entregarse a través de TLS. Los documentos se pueden cifrar con cualquier cifrado de dos maneras que se considere aceptable. La clave podría derivarse de la contraseña del usuario y solo se almacenaría en la memoria. Si alguno de los anteriores no fuera cierto, el cifrado de javascript sería superfluo de la siguiente manera:

  1. Si los documentos se pueden almacenar en el servidor, TLS podría cubrir el problema y el servidor puede tratar con el almacenamiento encriptado si es necesario.
  2. Si solo el propietario tiene acceso a la computadora, entonces los documentos podrían almacenarse en el almacenamiento local.
  3. Si la computadora es pública, entonces se podría instalar un registrador de claves o una versión maliciosa del navegador y no hay seguridad viable en ese caso.
  4. Si el usuario puede acceder a su trabajo sin una contraseña adicional, cualquier usuario puede acceder a su trabajo.
respondido por el Rick 12.06.2015 - 21:58
fuente

Lea otras preguntas en las etiquetas