texto - ¿Existen opciones de cifrado asimétrico para JavaScript?
encriptar json javascript (5)
¿Los mensajes de servidor> JavaScript se envían a través de HTTPS?
Si no, nada impide que un hombre en el medio cambie los guiones. Cualquier cifrado será inútil si se compromete el código que tiene acceso a los datos no cifrados.
Tengo que transferir información confidencial a través de una llamada AJAX de JavaScript, a través de un canal no cifrado (HTTP, no HTTPS).
Me gustaría cifrar los datos, pero el cifrado en el lado de JavaScript significa que expongo la clave, lo que hace que el cifrado simétrico solo sea un ejercicio de seguridad por oscuridad.
¿Hay algún cifrado asimétrico para JavaScript? De esa manera, puedo mantener en secreto la clave de descifrado del servidor. (No me preocupa la seguridad de los mensajes de Servidor> JavaScript, solo la seguridad de un determinado mensaje de Servidor> JavaScript)
Esta pregunta parece tener lo que está buscando , biblioteca de criptografía de Javascript para firmar datos de formulario en el navegador El enlace PGP: http://www.hanewin.net/encrypt/ tiene RSA
La clave pública asimétrica / clave privada es la única forma de hacerlo. Para protegerse contra los ataques MIM, el servidor puede codificar la clave pública con la contraseña del usuario, luego el usuario (en el navegador) vuelve a calcularla: si coinciden, el usuario puede estar seguro de que la clave pública enviada desde el servidor no tiene ha sido manipulado: esto se basa en el hecho de que solo el servidor y el usuario conocen la contraseña del usuario.
PD: quería escribir esto como un comentario, ya que sería más apropiado que una respuesta, pero no tengo suficientes puntos :)
La razón por la que necesita cifrado es para protegerse contra un hombre en el medio. Hay escenarios en los que un atacante puede detectar el tráfico sin poder cambiarlo. Esta solución protegería contra esa amenaza, pero no brindaría ninguna protección contra un intermediario que pueda modificar el tráfico.
Si el atacante puede cambiar el tráfico, también podrá cambiar la secuencia de comandos que realiza el cifrado. El ataque más fácil sería simplemente eliminar el cifrado completamente del script. Si no tiene https, y es posible un administrador en el medio (que es el caso en casi todos los escenarios), entonces no tiene ningún control sobre el código html o javascript que se presenta hasta el final usuario. El atacante puede reescribir completamente su código html y javascript, deshabilitar el cifrado, crear nuevos campos de formulario en su formulario, etc. Https es un requisito previo para una comunicación segura en el canal web.
Lo he hecho. Uso este cifrado RSA asimétrico del lado del cliente de JavaScript para evitar que las credenciales de inicio de sesión se envíen en texto sin formato a través de HTTP.
El objetivo es evitar los ataques de repetición de solicitudes de inicio de sesión basados en el rastreo de la red. Por supuesto, esto no es tan seguro como HTTPS ya que no resistiría los ataques de intermediarios, pero puede ser suficiente para las redes locales.
El cifrado del lado del cliente utiliza el excelente trabajo de Travis Tridwell que se basa en JSBN . La página web de Travis también puede generar las claves RSA privadas y públicas (si eres demasiado perezoso para usar openssl ). Las claves se generan en formato PKCS # 1 PEM. username+password+timeInMs+timezone para que el contenido cifrado cambie en cada inicio de sesión.
En el lado del servidor, mi código de Java leyó el archivo PEM PKCS # 1 utilizando el archivo org.apache.jmeter.protocol.oauth.sampler.PrivateKeyReader Apache JMeter :
PrivateKey pk = (new PrivateKeyReader("myPrivateKeyFile.pem")).getPrivateKey();
Luego descifro el contenido cifrado usando
byte[] enc = DatatypeConverter.parseBase64Binary(clientData);
Cipher rsa = Cipher.getInstance("RSA");
rsa.init(Cipher.DECRYPT_MODE, pk);
byte[] dec = rsa.doFinal(enc);
String out = new String(dec, "UTF8");
Luego verifico si la marca de tiempo / zona horaria del lado del cliente coincide con la marca de tiempo / zona horaria del lado del servidor. Si el retraso es inferior a unos pocos segundos, el proceso de inicio de sesión continúa. De lo contrario, la solicitud se considera un ataque de reproducción y el inicio de sesión falla.