Me gustaría utilizar JavaScript para cifrar la contraseña y el nombre de usuario de un usuario cuando inicie sesión (usando Ajax). Sé que existen varias bibliotecas de cifrado asimétricas para JavaScript. ¿Es esta una estrategia viable para la seguridad de las contraseñas?¿Es viable el cifrado de contraseñas de forma asimétrica utilizando JavaScript?
Entiendo que SSL existe, pero esa no es la pregunta.
No. No importa si el atacante recibe la contraseña o la contraseña cifrada, ambas se envían al servidor "sin cifrar", por lo que la contraseña cifrada se puede utilizar para iniciar sesión.
JavaScript no se puede utilizar para la seguridad. Usted tiene para usar HTTPS.
¿Qué pasa si ese algoritmo de cifrado se mantuvo en un método privatizado? – GAgnew
¿Por qué es necesariamente el caso? ¿Qué pasa si instalo una biblioteca SHA1 (como esta: http://pajhome.org.uk/crypt/md5/sha1).html) y solo enviar hash de contraseñas a través de la red? Si esto no es seguro, ¿no está almacenando hash SHA1 en bases de datos inseguras? –
Si el paquete cifrado contuviera una marca de tiempo, limitaría el tiempo de validez de la contraseña cifrada. Aún mejor, primero solicite un token del servidor que se agrega a la contraseña antes del cifrado, cada token solo se podría usar una vez. –
No creo que tenga mucho que ganar al hacer esto, ciertamente menos que el rendimiento que una pieza de JavaScript tan matemáticamente intensiva impondría. Si está usando esto para cifrar una parte de los datos antes de enviarlos al servidor a través de HTTP, entonces si bien habrá protegido a un pirata informático para que no descubra exactamente cuál es la contraseña, no habría impedido que obtuviera acceso simplemente ejecutando un ataque de repetición con la misma información encriptada que ha enviado.
La única forma viable de proteger un envío de formularios es usar HTTPS. Sé que configurar HTTPS es una molestia, con los certificados que solo funcionan en un dominio y todo eso, pero si la información realmente es crítica, entonces es una mejor inversión de tiempo que tratar de hacer el cifrado en JavaScript.
Las matemáticas en javascript ya son bastante rápidas, el javascript se considera lento porque la mayoría de las veces se asocia con el complejo proceso de manipulación de DOM difícil de abstraer. Ver [esta demostración] (http://bitwiseshiftleft.github.com/sjcl/demo/) (encriptación simétrica). –
Todavía hay problemas con este modelo porque todavía está pasando el texto a través de la conexión. Sin una cierta medida de una fecha en el proceso de encriptación/descifrado/comparación, usted todavía tiene el potencial para un ataque de repetición.
Incluso más allá del ataque de hombre en el medio que aún prevalecería, aún tendrías el hecho de que tu algoritmo de encriptación y clave pública estaría disponible. Si alguien fuera a tener una contraseña cifrada, entonces tendría una fuente permanente desde la cual usar esa contraseña tan fácilmente.
Paso uno: no confíe en las personas en Internet, propondré un algoritmo débil para asegurar que pueda romperlo.
Paso dos: No diseñe su propio algoritmo, o implementar cualquier otra persona que está en un sistema de producción hasta que tenga un PHD en la seguridad informática
cifrado no es suficiente para proteger contra ataques de repetición, si un atacante obtener el contraseña encriptada, les sirve tanto como una contraseña no encriptada si es suficiente para autenticarse.
que sugeriría:
Todos los datos transmitidos seguirán estando visibles, por lo que los usuarios no obtendrán ninguna privacidad (como lo harían en https). Su algoritmo de cifrado, implementación de cifrado y clave pública serán públicos. Este es el caso de una gran cantidad de cryptolagy actual, una gran cantidad de algoritmos están diseñados para ser seguros con el atacante sabiendo esto.
Esto no protegerá contra ningún keylogger o ataque de spyware, ya que apuntarán antes de cifrar la contraseña.
No tengo conocimiento de las implementaciones de cifrado asimétrico implementadas en JavaScript, pero no hay nada fundamentalmente inseguro en este enfoque.
30 segundos? ¿Qué pasa si tengo que buscar mi contraseña porque la hice tan fuerte que no puedo recordarla de memoria? –
Entonces, basado en su primer punto, ¿debería confiar en el sistema que usted propuso? –
@SimpleCoder Nope :) Tengo una inseguridad de interés y creo que esto lo hará más seguro, pero solo soy el diablo malvado que te engaña. En serio, creo que lo que digo es correcto, pero tú solo tienes mi palabra y puedo estar equivocado. –
Puede usar un algoritmo como Secure Remote Password protocol para proporcionar una prueba de conocimiento cero de que conoce la contraseña. Un espía no podrá usar esto para replicar su inicio de sesión. Sin embargo, tenga cuidado con un atacante activo que reemplace su código JavaScript con algo que le transmita la contraseña directamente.
Existen varias implementaciones de Javascript de SRP:
Si vas a empezar de un no-autenticar la comunicación que está siempre en riesgo de man-in -la mitad.
De todos modos, transmitir una contraseña salada y hash es siempre mejor que transmitir la contraseña simple. Debido a que tal vez su sistema de inicio de sesión es débil, pero al menos no está compartiendo la contraseña del usuario (que puede ser compartida con otro sistema, tal vez utilizado para la cuenta bancaria).
Además, no almacene ese valor, sino sal y hash de nuevo.
Si también utiliza encriptación asimétrica, agrega protección contra escuchas ilegales. Pero, de nuevo, no contra el hombre en el medio.
Gracias por la revisión, Michael Petrotta; Supongo que mi corrector ortográfico no estaba activado después de todo :) –
¿Por qué no solo usas HTTPS? –
@Alin Purcaru: Pregunta actualizada –