¿Existe alguna amenaza de seguridad debido a la devolución de la contraseña en el formulario que envió la falla (por ejemplo, en una página de registro)?

Molesto, ¿no es así? La seguridad y la facilidad de uso a menudo están en desacuerdo.

En este caso, el riesgo es bastante pequeño, pero está ahí. Imagina lo siguiente:

1. Usted ingresa toda su información, incluida la contraseña, y la envía
2. Perdiste temporalmente tu conexión wifi, o algo sucede en la red para que la respuesta sea increíblemente lenta
3. Perdiendo la paciencia, te alejas de la computadora
4. Un minuto después, la página finalmente se procesa, incluida su contraseña
5. Un usuario malicioso se acerca, hace clic en Inspeccionar elemento y aprende la contraseña

Por supuesto, no es una contraseña que funcione (después de todo, su registro falló), pero tal vez use la misma contraseña para todo. ¿Quién sabe? De todos modos, el riesgo es bastante pequeño aquí.

También hay un problema de usabilidad. La contraseña puede haber sido sobrescrita por uno de sus complementos de administrador de contraseñas o el anillo de claves de iCloud o algo así. Dado que no puede ver el valor de la contraseña, no puede estar 100% seguro de que se establece en el valor deseado cuando vuelva a enviar el formulario. Si está mal, terminarás encontrando todo tipo de dolor y confusión. Así que quizás sea más seguro hacer que lo escribas de nuevo.

Personalmente, si estuviera diseñando el sitio web, pondría los campos de ingreso de datos de contraseña en su propia página, después de que haya completado con éxito todos los otros campos, incluido CAPTCHA.

Otro vector de ataque a considerar es el secuestro de sesión. Suponiendo que esté utilizando Post-Redirect-Get (que debería ser en general), tendría que guardar la contraseña en la sesión para poder reenviarla a través de GET. Si bien la sesión en sí misma se encuentra en un lugar relativamente seguro y confiable (en su servidor), el almacenamiento de texto sin formato o contraseñas cifradas de manera reversible hace que su sesión almacene un objetivo aún mayor. Pero digamos que eso es lo que haces.

Supongamos que un atacante obtiene o diseña la variable de sesión del usuario. El usuario ingresa la contraseña pero falla el formulario. Quienquiera que emita una solicitud GET con esa variable de sesión (que podría ser el atacante) recibe la contraseña sin cifrar. Esto es peor que un secuestro de sesión estándar, porque un secuestro estándar solo permitiría al atacante hacerse pasar por el usuario, no obtener contraseñas que podrían ser válidas para otros sitios.

Por supuesto, puede mitigar esto mediante cualquier sesión estándar de secuestro de defensas, regenerando el token en carga, o simplemente procesando en la publicación para evitar la sesión por completo. (Por favor, no hagas eso. Tener un error en el navegador cuando vuelvo a abrir o volver a cargar una página es frustrante, especialmente porque lo hago mucho gracias al no-script).

Cuantos menos lugares exista la contraseña, menos objetivos de ataque. Si debe hacer esta función, vaya con la sugerencia de comentarios de Andre para eliminar el campo de la contraseña por completo con un botón para cambiarla, o complete el campo de la contraseña con una contraseña estándar pero no válida (es decir, menor que su longitud mínima) que pueda compruebe cuándo ha guardado una contraseña. Simplemente no envíe contraseñas reales, incluso a través de HTTPS.