Solución:
En principio, los valores almacenados en sessionStorage están restringidos al mismo esquema + nombre de host + puerto único, y si el navegador tiene una salida limpia, estos valores deben eliminarse al final de la sesión. Sin embargo, según esta publicación, puede sobrevivir al reinicio del navegador si el usuario elige “restaurar la sesión” después de un bloqueo (lo que significa que sus valores también existen en la memoria persistente hasta que se borran, así que tenlo en cuenta). Si se implementa bien, diría que es lo suficientemente seguro, especialmente en comparación con su alternativa de usar una cookie (que tiene muchas trampas que ni siquiera consideraría). La Especificación W3C también establece que el almacenamiento web podría usarse para almacenar datos confidenciales (aunque no está claro si esa práctica está respaldada o no).
En cuanto a los riesgos, es simplemente una cuestión de compensaciones: está haciendo que su sitio sea un poco más conveniente para sus usuarios, mientras aumenta un poco la ventana de oportunidad para que la contraseña sea capturada (ya sea por medio de una vulnerabilidad XSS, por el valor persiste en el almacenamiento persistente durante más tiempo de lo que pretendía, o si el usuario deja la computadora desatendida antes de finalizar el registro). Idealmente, las contraseñas nunca deberían salir de la RAM, pero eso suele ser poco práctico, por lo que es necesario un compromiso. Solo recomendaría borrar la contraseña de sessionStorage tan pronto como el registro sea exitoso, y estar atento a las vulnerabilidades en las implementaciones de sessionStorage que eventualmente puedan salir a la luz.
Sugiero otro enfoque: en lugar de enviar el formulario al servidor, utilice XMLHttpRequest para crear la cuenta. Si falla la validación del lado del servidor, el formulario y todo su contenido aún están disponibles. Si tuvo éxito, redirija a la página de destino.
Esto requiere que JavaScript esté habilitado, pero aún puede volver al envío normal de formularios. El acceso a SessionStorage también requiere JavaScript.
Tendrá dificultades para decidir cuál de los dos valores almacenados utilizar como contraseña deseada del usuario (la del almacenamiento local o la del campo de entrada), si ninguno de ellos está vacío pero por alguna razón difiere.
Esto puede potencialmente proporcionar un vector de ataque de ingeniería social, donde el atacante prepara una trampa abriendo el formulario de registro, llenando el almacenamiento local / de sesión usando su propio código y luego eliminando cualquier rastro del mismo (notificaciones de error de entrada) con un DOM editor, o ingresando la contraseña deseada directamente en el almacenamiento local / de sesión (ambos son compatibles con algunos navegadores y son extremadamente fáciles de hacer), y luego pedirle a la víctima que se registre en su sitio web y, bueno, que lo use. Dado que su código se puede inspeccionar / probar fácilmente para ver cómo maneja tales casos, el atacante podría hacer esto de manera ligeramente diferente a lo que describí (incluso las inyecciones de script directamente en el almacenamiento local / de sesión no están fuera de discusión, si luego procesa ese valor localmente en el formulario POST), pero con el mismo efecto.
La víctima no sospechará nada hasta que cierre la sesión e intente volver a iniciar sesión. Dependiendo de cuán persistente sea la sesión del usuario, este proceso de cerrar sesión y volver a iniciar sesión podría no ser necesario, y la víctima no la habría notado. La contraseña no fue la que ingresó en el campo de contraseña, sino que se usó la contraseña elegida por el atacante para crear su nueva cuenta.
Es necesario decir que el atacante acaba de obtener acceso a la cuenta recién creada de la víctima y a todos los datos que ingresó, incluso si la víctima fue cautelosa y se aseguró de que no se tratara de navegar por el hombro.
Entonces, la conclusión aquí es que potencialmente tendrá que lidiar con dos ubicaciones diferentes de los mismos datos de registro del sistema, que pueden diferir por cualquier motivo, y decidir cuál usar de una manera que sea segura tanto para su sistema como para el usuario final que se está registrando. Esto puede resultar bastante complicado de hacer correctamente, por lo que no lo desaconsejaría.
En su lugar, asegúrese de que su formulario de registro se envíe a través de HTTPS, y luego simplemente complete el campo de contraseña de nuevo, como se ingresó por última vez en la solicitud POST del usuario y si satisface sus restricciones, incluso si algunos de los otros campos de entrada se completan incorrectamente y el formulario necesita volver a publicarse.