¿Podría un usuario nunca almacenar una contraseña si en su lugar se usó un hash de nombre de usuario / correo electrónico?

Si el protocolo que utilizas es vulnerable a los ataques Man-in-the-Middle , luego, pierde de todos modos, independientemente de la cantidad de hash que aplique: el atacante MitM puede esperar a que se realice su autenticación y luego secuestra la conexión en ese momento. Sin embargo, debo decir que SSL es NO vulnerable a MitM, siempre y cuando nadie haga algo estúpido (por ejemplo, mirando una gran advertencia roja del navegador que dice "este servidor usa un certificado no válido "y haciendo clic en" shuddup, quiero conectarme de todos modos " es " algo estúpido ").

Así que estamos hablando de un usuario que hizo algo lo suficientemente malo como para infringir SSL; y el mismo usuario también reutilizó la misma contraseña en varios sitios. Desafortunadamente, hay muchos usuarios que hacen tales cosas. Su propuesta tiene dos problemas principales:

• El almacenamiento de contraseñas debe usar hashing de contraseña , con sales y lentitud . Se aplica una gran cantidad de iteraciones, de modo que un atacante que podría volcar la base de datos del servidor todavía sufre mucho al intentar descifrar las contraseñas. Pero en su caso, este hash DEBE necesariamente ocurrir en el lado del cliente, en Javascript. Javascript está lejos ( muy lejos) de tener suficiente músculo para hacer eso. Esto implicaría dividir el recuento de iteraciones por al menos 10 (probablemente más) para que el tiempo de inicio de sesión sea tolerable, por lo que dividir por al menos 10 de seguridad contra un ataque de diccionario sin conexión.

• Javascript . El código que hace el hashing acaba de ser servido por el propio servidor, a través de la conexión que asumimos que estaba bajo un ataque MitM. Tal atacante puede modificar este Javascript a voluntad. Es decir, puede agregar un poco de Javascript extra que también envía el nombre de usuario y la contraseña (tal como lo ingresó el usuario) a su propio servidor malvado.

El segundo punto hace que el debate sea discutible: si un atacante puede ejecutar un MitM exitoso, entonces puede tomar la contraseña de la fuente, es decir, el campo de entrada en la página web, y ninguna cantidad de Javascript puede cambiar eso.

Sí. Por Tom Leek , esto no se puede hacer en el servidor. Hay extensiones de navegador que contienen contraseñas de hash (que utilizan el dominio como parte de la contraseña no lavada) antes de enviarlas a un servidor. Esto no proporciona protección contra todos los ataques MiTM, aunque sí protege contra algunos tipos de ataques.

Este enfoque tiene algunos beneficios:
1. Los usuarios pueden usar la misma contraseña en todos los sitios, sin las vulnerabilidades asociadas. 2. Los sitios de phishing reciben la contraseña "incorrecta".
3. La contraseña con hash suele ser criptográficamente más fuerte que la contraseña original.

Y algunas desventajas:
1. El usuario debe confiar en la extensión.
2. Si la extensión usa hashing roto, la situación del usuario no es sustancialmente mejor que si el usuario hubiera utilizado la misma contraseña en cada sitio.
3. Es posible que la contraseña generada no se acepte en algunos sitios (por ejemplo, considere dos sitios, uno que no acepta las contraseñas contiene símbolos y otro que requiere símbolos). Hacer esto configurable es posible, pero hace que el programa sea más difícil de usar.
4. Esta protección puede fallar si el usuario escribe la contraseña directamente en el sitio, ya que el sitio podría estar escuchando a través de javascript. Las herramientas de hash bien diseñadas mitigarán dichos ataques mediante el uso de una clave privada única como parte del hash.
5. Suponiendo que el usuario tenga una clave privada, el inicio de sesión en un sitio fallará si el usuario está en una computadora diferente o si su computadora actual pierde la clave (debido a una actualización o similar). Si esta clave privada está basada en contraseñas, entonces la solución basada en hash es inútil; en ese punto es un administrador de contraseñas glorificado.