¿Es seguro almacenar la contraseña en HTML5 sessionStorage?

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 a una reinicie el 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 borren, así que tenga eso en cuenta). Si estuviera bien implementado, diría que es lo suficientemente seguro, especialmente en comparación con su alternativa de usar una cookie (que tiene muchos inconvenientes que ni siquiera consideraría). La especificación W3C también establece que el almacenamiento web se puede utilizar para almacenar datos confidenciales (aunque no está claro si esa práctica está o no aprobada).

En cuanto a los riesgos, es simplemente una cuestión de compensaciones: está haciendo su sitio un poco más conveniente para sus usuarios, mientras que aumenta un poco la ventana de oportunidad para que la contraseña sea capturada (ya sea por medio de un XSS vulnerabilidad, por el valor que persiste en el almacenamiento persistente durante más tiempo del que pretendía, o por el usuario que deja la computadora desatendida antes de finalizar el registro). Lo ideal es que las contraseñas nunca deban salir de la memoria RAM, pero eso no suele ser práctico, por lo que es necesario un compromiso. Solo le recomiendo que elimine la contraseña de sessionStorage tan pronto como el registro sea exitoso, y que vigile las vulnerabilidades en las implementaciones de SessionStorage que eventualmente salgan a la luz.

Le resultará difícil decidir cuál de los dos valores almacenados se usará como la contraseña deseada del usuario (la que está en el almacenamiento local o la que está en el campo de entrada), si ninguno de ellos está vacío, pero para algunos razón difiere.

Esto potencialmente puede 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 (notificaciones de error de entrada) con un editor de DOM, o ingresando la contraseña deseada directamente en el almacenamiento local / de sesión (ambos son compatibles con algunos navegadores y es extremadamente fácil de hacer), y luego le pide a la víctima que se registre en su sitio web y, bueno, la use. Ya que su código puede ser fácilmente inspeccionado / probado para ver cómo maneja estos casos, el atacante podría hacer esto de manera ligeramente diferente a lo que describí (incluso las inyecciones de scripts directamente en el almacenamiento local / de sesión no están fuera de la cuestió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 iniciarla. Dependiendo de la persistencia de la sesión del usuario, este proceso de cierre de sesión e inicio de sesión podría no ser necesario, y la víctima no lo haría. noté que su contraseña no era la que ingresó en el campo de la contraseña, sino que la contraseña elegida por el atacante se usó para crear su nueva cuenta.

En pocas palabras, el atacante acaba de acceder a la cuenta recién creada de la víctima y a todos los datos que ingresó, incluso si la víctima era cautelosa y se aseguró de que no se trataba de navegar por los hombros.

Por lo tanto, lo importante es que posiblemente tenga que lidiar con dos ubicaciones diferentes del mismo sistema de datos, que podrían diferir por cualquier motivo, y decidir cuál usar de una manera que sea segura para su sistema. así como el usuario final que se está registrando. Esto puede resultar bastante difícil de hacer correctamente, por lo que aconsejaría no hacerlo.

En lugar de eso, asegúrate de que tu formulario de registro se sirva a través de HTTPS, y luego simplemente rellena el campo de contraseña, ya que se ingresó por última vez en la solicitud POST del usuario y si cumple con tus restricciones, incluso si algunos de los otros campos de entrada son Rellenado incorrectamente y el formulario debe ser enviado de nuevo.

Sugiero otro enfoque: en lugar de enviar el formulario al servidor, use un XMLHttpRequest para crear la cuenta. Si la validación del lado del servidor falla, el formulario y todo su contenido todavía están disponibles. Si tuvo éxito, redirigir a la página de destino.

Esto requiere que JavaScript esté habilitado, pero aún puede volver a enviar el formulario normal. El acceso a SessionStorage también requiere JavaScript.

Usaría alguna comunicación intertab para distribuir la contraseña en lugar de almacenarla en cualquier almacenamiento persistente (cookie, almacenamiento local, etc. Hay innumerables soluciones, verifique evercookie). De esta manera, la contraseña vivirá en el navegador hasta que cierre la última pestaña del dominio real.

Puedes hacer una comunicación entre pestañas de forma segura con BroadcastChannel o SharedWorker o postMessage probablemente haya otros métodos que no conozco, siempre están reinventando la rueda. Los dos primeros envían los mensajes a todas las pestañas, el último solo se envía a las pestañas abiertas desde la misma pestaña principal, por lo que es algo restrictivo, pero es compatible con más navegadores.

Si almacena sus contraseñas en la memoria js, debe evitar XSS con encabezados especiales . Y ofc. necesita verificar el contenido mostrado para las etiquetas HTML y siempre debe JSON codificar los datos que desea inyectar directamente en javascript como variable.

La publicación de TildalWave es interesante, creo que estos métodos no son vulnerables a eso, porque la sincronización es casi instantánea y puedes sincronizar el inicio de sesión, el cierre de sesión, etc. también.

Si decides usar localstorage de todos modos, es mejor usar un ID de usuario firmado, timeout y salt en lugar de la propia contraseña. Puede enviar las credenciales al servidor, que puede verificarlas, y enviar los datos con la firma de vuelta. Se pueden almacenar en una cookie o en cualquier almacenamiento persistente que desee. Estos tokens a veces son utilizados por las API REST si hay un cliente de navegador, porque esta solución no tiene estado y aún da la sensación de tener una sesión clásica. A veces, firman todas las solicitudes, no solo la identificación del usuario para mejorar la seguridad.