Cuando falla el envío del formulario, el campo de la contraseña se queda en blanco, ¿por qué es así?

Buena pregunta. Al tener la ventaja de ver algunas de las respuestas y reflexionar sobre esto yo mismo, en realidad no veo ningún beneficio de seguridad major al borrar la contraseña del formulario parcial que se devuelve al usuario, pero definitivamente hay Hay algunos riesgos que vale la pena considerar.

Desde el punto de vista de arquitectura de seguridad (ya que @Roryalsop ya se ha tocado), por lo general, las contraseñas fluyen solo en una dirección. Del usuario a la aplicación, nunca más atrás. Esto se aplica a todas las capas, y este sistema unidireccional brinda beneficios desde un punto de vista de seguridad. Tener una excepción a esta regla puede o no ser una buena idea. Pero es por eso que tu pregunta es interesante. ¿Este escenario merece una excepción?

Observemos algunos vectores de ataque y veamos si anular la contraseña protege contra alguno de estos:

• Detección del tráfico : si un atacante puede interceptar la comunicación entre el usuario y el servidor, puede detectar la contraseña enviada en primer lugar por el usuario. No veo ningún beneficio en vaciarlo en la respuesta
• malware en el servidor o en el lado del cliente : lo mismo. Puede interceptar la contraseña inicial.
• datos almacenados en caché : esto ya se mencionó brevemente en @SachinKumar, pero vale la pena ampliarlo. Existe una mayor posibilidad de que si el servidor devuelve la contraseña con la respuesta, podría terminar en caché en algún lugar (el servidor de memcached, un servidor proxy a lo largo de la ruta, el historial del navegador del cliente, etc.). Las solicitudes de los clientes nunca se almacenan en caché. Las respuestas del servidor son! Este es probablemente el mayor riesgo que veo. Los proxies probablemente se pueden eliminar de la ecuación usando SSL, y si el servidor usa encabezados de caché correctos y establece el campo de entrada correctamente, esto también puede mitigar el almacenamiento en caché del navegador. Dicho esto, todavía es posible que el valor se almacene en caché en algún lugar, incluso accidentalmente, y probablemente no sea deseable.

Pero luego, anular la contraseña es bastante fácil, no debería dañar demasiado la experiencia del usuario y mantener las cosas más limpias desde el punto de vista de la seguridad. Todavía te sugiero que sigas haciéndolo.

Si le preocupa la experiencia del usuario, intente siga los consejos que ya le dieron en UX: realice Validación adicional en el lado del cliente, solo para que el usuario reciba comentarios tempranos. No reemplace la validación en el servidor. Esta es la validación más importante en última instancia. Pero para la retroalimentación del usuario, la validación del lado del cliente puede hacer maravillas para mejorar la experiencia del usuario y no tiene que correr el riesgo de que la contraseña se almacene en caché (o cambie su arquitectura de seguridad haciendo una excepción).

  

¿Por qué es inseguro volver a publicar el mismo pase que el usuario ha ingresado?

Porque si luego ve la fuente en la página publicada atrás, la contraseña será visible en texto sin formato. Esto va en contra del principio de que las contraseñas deben ser solo de una manera, es decir, las contraseñas pueden ingresarse pero nunca entregarse. Por ejemplo, cuando se almacenan contraseñas en la base de datos, éstas deben estar marcadas en lugar de cifradas para evitar que se extraigan si un atacante logra ver los datos. Seguir este principio en todas partes conducirá a un sistema más seguro.

En este caso, puede evitar la "navegación por los hombros" y puede evitar que el navegador lo almacene en caché y luego se visualice.

Es posible tener una buena interfaz de usuario y seguir este principio. Por ejemplo, el sistema podría almacenar la contraseña con hash y con sal en el estado de la sesión del lado del servidor, y luego, en la respuesta, el formulario solo muestra los otros campos. Una vez que esto haya pasado la validación, se usa la contraseña del estado de la sesión en lugar de las que el formulario hubiera proporcionado. Por supuesto, se debe tener cuidado aquí para invalidar la sesión si el usuario no continúa con el proceso de registro para que esta contraseña no anule la establecida por el siguiente visitante de ese navegador. de lo contrario, puede ser posible un ataque de fijación de sesión .

2 puntos clave aquí:

1. Si tiene un mecanismo para enviar la contraseña al usuario, le da a un atacante una forma de obtener esa contraseña.
2. Si puede enviar la contraseña al usuario, significa que no está almacenando el hash, sino que usa un texto claro o un cifrado reversible. sin embargo como lo señala @yoav, en un escenario particular, la TI aún no se habrá cifrado, por lo que este punto es irrelevante aquí.

Ambos de estos tienen riesgos.

Esta es la razón por la que la mayoría de los sitios web tienen recordatorios de contraseña y mecanismos de restablecimiento, por lo que no necesitan devolverle la contraseña. Es posible que le envíen una contraseña única como restablecimiento, que luego deberá cambiar.

Algunos enviarán tu contraseña en una ruta fuera de banda, pero se están haciendo cada vez más raras a medida que aumentan los riesgos.

(por supuesto, la seguridad de los mecanismos de restablecimiento de contraseña es otra cuestión)