¿Es una mala práctica informar al usuario sobre su contraseña con hash?

Me parece una exposición innecesaria. Esperemos que no sea simplemente hash, sino que con una sal aleatoria por usuario considerable y un KDF con muchas iteraciones. Aun así, la intención del diseño es mantenerlo protegido en el servidor, no enviarlo a los clientes.

Si, como usted dice, el campo oculto se envía fuera del servidor solo tras la autenticación adecuada, el riesgo es mucho menor (por lo que un pirata informático no sería capaz de recopilar hashes fácilmente al intentar restablecer un montón de contraseñas de usuarios), pero aún parece innecesario.

La razón por la que todavía estamos hablando de riesgo es que los sistemas y redes de usuarios finales son mucho más fáciles de espiar, que los servidores protegidos de forma consciente. Entonces, si en este caso un atacante tiene una posición privilegiada en una red que usa la eliminación de SSL en su perímetro, entonces (s) no necesitaría "piratear el servidor", por lo tanto, eludir las protecciones del lado del servidor.

Podríamos argumentar que "la cuenta de usuario se eliminará de todos modos", y hasta cierto punto sería cierto (menor riesgo). Aún así, es bueno tener un caché de contraseñas usadas (si se pueden derivar de los hashes), ya que la reutilización de la contraseña es rampante.

La forma en que lo describió anteriormente, es probablemente una mala práctica. Su navegador web no debería tener que guardar su contraseña (o su contraseña hash) después de la primera autenticación. El enfoque estándar es utilizar autenticación basada en token , donde se autentica una vez y luego el servidor devuelve un token de autenticación a su máquina que no incluye su cuenta o su contraseña en de cualquier manera.

enlace

En este caso, el principal beneficio es que la contraseña o su hash no está flotando por más tiempo del necesario. El servidor debe devolver un token a su máquina que le dé permiso para eliminar su cuenta después de completar el segundo formulario.