GWT/Javascript cifrado de la contraseña del cliente

Question

estoy poniendo en práctica la autorización en mi aplicación GWT, y en el momento que se hace de la siguiente manera:

1. el usuario se registra por poner sus credenciales en una forma, y Los envío en texto claro al servidor.
2. El código del servidor codifica la contraseña recibida utilizando BCrypt y coloca el hash en una base de datos.
3. Cuando el usuario inicia sesión, su contraseña se envía clara al servidor, que la comprueba contra el hash almacenado.

Ahora. Lo que me molesta de esto es el hecho de que estoy enviando la contraseña al servidor sin tapujos, sigo pensando que no estaría muy contento si una aplicación que estaba usando hiciera eso con mi (use-for- todo-bueno) contraseña, pero encriptarla en el cliente realmente no me ganaría nada, ya que los atacantes podrían simplemente usar la contraseña hash como lo harían con la clara.

He estado googling todo el día para esto, y parece que Internet es bastante unánime cuando se trata de esto: aparentemente no hay nada que ganar con el cifrado de contraseñas del lado del cliente. This, this y this son solo algunos ejemplos de las discusiones y páginas que he visitado, pero hay muchas, muchas más, todas diciendo lo mismo.

Esta pregunta, a la luz de todo esto, puede parecer un poco innecesaria, pero espero que en algún lugar, alguien, tenga otra respuesta para mí.

¿Qué puedo hacer yo, si SSL no es una opción en este momento, para aliviar mi mente acerca de esto? ¿Hay algo que hacer, o implementar algún tipo de esquema cliente-encriptar-servidor-descifrar, solo será una patada de caballo muerto débil y lento?

Answer 1

Para iniciar sesión, SSL debe ser su opción, incluso en este punto.Si es sólo para la conexión, no es necesario una granja SSL caro, pero al menos se protege la contraseña (use-para-todo-tipo), a pesar de que está claro, que la comunicación restante no está asegurada ^[*]. Esto puede significar que necesita comprar un certificado para un solo servidor de inicio de sesión, lo que puede ahorrarle una gran cantidad de dinero, dependiendo del proveedor del certificado.

Para GWT, si usted no puede permitirse el lujo de cifrar todas las comunicaciones, que tendrá que poner el inicio de sesión en una página separada debido a limitaciones de Política mismo origen.

Si todavía no es una opción, puede pensar en iniciar sesión a través de OpenID, al igual que stackoverflow.

No puede haber cualquier comunicación segura a través de medios inseguros y sin algunos pre-secreto compartido - por lo general proporcionada por los certificados raíz que se instalan en un navegador (Por cierto, es curioso/miedo que los navegadores e incluso la totalidad los sistemas operativos generalmente se descargan a través de HTTP). Otros sistemas, p. PGP, confíe en la confianza previamente establecida en un "Web Of Trust", pero esta es solo otra forma de secretos precompartidos. No hay forma de evitarlo.

^{[*] Usar SSL para todo, lamentablemente, viene con problemas prácticos adicionales: 1) Las cargas de página son mucho más lentas, especialmente si tiene muchos elementos en la página. Esto se debe a los viajes redondos inducidos por SSL y la latencia resultante, que no se puede contrarrestar ni siquiera con la granja SSL más rápida. El problema se mitiga, pero no se elimina por completo mediante las conexiones de mantener vivo. 2) Si su página incluye elementos de sitios ajenos a HTTPS (por ejemplo, imágenes insertadas por usuarios), muchos navegadores mostrarán advertencias, que son muy vagas sobre el problema real de seguridad y, por lo tanto, son generalmente inaceptables para un sitio seguro.}

Algunas reflexiones adicionales (no una recomendación)

Asumamos que el peor de los casos por un momento, es decir, que no se puede utilizar SSL en absoluto. En ese caso, tal vez sorprendentemente, hash la contraseña (con una sal) antes de transmitirlo, en realidad puede ser un poco mejor que no hacer nada. Esta es la razón: no puede derrotar a Mallory (en criptografía, una persona que puede manipular la comunicación), pero al menos no permitirá que Eve (una persona que solo puede escuchar) lea la contraseña de texto plano. Esto puede valer algo, si asumimos que las vísperas son más comunes que Mallory (?) Pero tenga en cuenta, que en ese caso, debe hash de la contraseña nuevo (con una sal diferente), antes de compararlo con el valor de base de datos.

Answer 2

Si SSL no es una opción, entonces, obviamente no le importa lo suficiente sobre la seguridad;)

Pero en serio - como usted ha mencionado, el cifrado por parte del cliente de la contraseña no es una buena idea. De hecho, es muy malo. Usted no puede confiar en el lado del cliente para jack - qué pasa si un atacante logró alterar el código JS (a través de XSS o mientras fue enviado a través del cable), para que su función hash MD5/lo pase en texto claro ? Sin mencionar que deberías utilizar un método de encriptación bueno, fuerte y salado, como bCrypt, algo que es lento para el cliente y como se mencionó anteriormente, no contribuye a la seguridad de la aplicación.

Podría intentar pasar por alto algunos de esos problemas: enviando la biblioteca hash a través de algún medio seguro (si eso fuera posible en primer lugar, no tendríamos que molestarnos con todo esto ahora, ¿verdad?), Por de alguna manera compartir un secreto común entre el servidor y el cliente y el uso que para el cifrado ... pero la conclusión es: utilizar HTTPS cuando sea posible (en GWT es difícil de mezclar HTTPS y HTTP) y justificado (si el el usuario es lo suficientemente estúpido como para usar la misma contraseña para su aplicación no relacionada con la seguridad y para su cuenta bancaria, entonces es muy probable que haya usado la misma contraseña en varios otros sitios, cualquiera de los cuales podría llevar a secuestrar el contraseña). Otros medios solo lo harán pensar que su aplicación es más segura de lo que es y le harán menos vigilante.

Answer 3

considerar el uso de SRP.

Pero eso no ayudará si un hombre en el medio le envía Javascript mal que envía simpy una copia de su contraseña al servidor atacantes.