¿Volver a mostrar la contraseña en forma de registro, buena o mala?

6

Cuando un usuario intenta registrarse y los datos que envía no son correctos, como un correo electrónico incorrecto o una contraseña débil, le mostraremos nuevamente la página de registro con los datos que acaba de enviar junto con los mensajes de error.

Mi pregunta es ¿deberíamos mostrar la contraseña que acaba de enviar en HTML como esta?

<input type="password" value="s0me7Xpwd">

¿O simplemente déjelo en blanco y le molesta que ingrese otro?

Definitivamente, es mejor en la experiencia del usuario volver a insertar la contraseña (especialmente cuando la contraseña está bien), pero ¿sería bueno con respecto a la seguridad?

    
pregunta datasn.io 18.04.2015 - 11:42
fuente

1 respuesta

2

Esto no es un problema en sí mismo, pero en mi opinión, una aplicación web debería implementar la política de que las contraseñas solo se ingresan, nunca se generan. Seguir esta política dará como resultado un sistema mucho más seguro en lo que respecta al manejo de contraseñas.

Si va a hacer esto, asegúrese de configurar los encabezados adecuados para evitar el almacenamiento en caché en el navegador o en cualquier servidor proxy en ruta:

Cache-Control: private, no-cache, no-store, max-age=0, no-transform
Pragma: no-cache
Expires: 0

Tenga en cuenta que la contraseña seguirá siendo visible si se hace clic en la fuente de la vista en el navegador del usuario. Esto es un riesgo adicional, aunque es muy poco probable que un usuario muy normal lo haga. La única vez que podría pensar que la contraseña podría "escaparse" de esta manera es si el usuario decide guardar el HTML de la página localmente utilizando la funcionalidad de guardar la página de su navegador.

Puede almacenar la contraseña en la sesión una vez que se haya validado con cualquier política de requisitos de contraseña y coincida con la confirmación. Entonces, simplemente podría incluir algún código para suprimir la salida de los campos de contraseña si la contraseña ya ha sido aceptada por su aplicación. La desventaja de este enfoque es que las contraseñas se guardan en la memoria por más tiempo del necesario, lo que significa que su aplicación tiene un riesgo ligeramente mayor de ataques de memoria. Heartbleed fue uno; por supuesto, necesita que exista la vulnerabilidad para que aumente el riesgo de exposición de esta manera. . Una forma de mitigar esto es hash la contraseña lo antes posible y almacene el hash y el salt en la memoria.

Si desea permitirle al usuario la opción de cambiar su contraseña, puede generar un campo con un "valor mágico" en lugar de la propia contraseña.

<input type="password" value="notrealpassword">

Luego simplemente detecta si el usuario edita posteriormente este campo para saber si debe actualizar la contraseña almacenada en la sesión.

    
respondido por el SilverlightFox 21.04.2015 - 11:55
fuente

Lea otras preguntas en las etiquetas