Volver a llenar un campo de contraseña en un formulario ¿es un problema de seguridad?

Question

Me pregunto si debería volver a llenar el campo de contraseña (enmascarado) en un formulario cuando otros campos no se validan. He visto tanto en la web donde la forma sería ya sea:

1. volver a poblar el campo de la contraseña enmascarada
2. vacío el campo de contraseña, por lo que el usuario necesita para ponerlo de nuevo (aunque era válida)

¿Cuál es su mejor práctica? ¿Volver a poblar el campo de contraseña indica un agujero de seguridad? En cuanto a la usabilidad, preferiría volver a llenar el campo y que el usuario no vuelva a ingresarlo.

Answer 1

Una opción si desea hacer esto, no es en realidad enviar la contraseña de texto sin formato, sino un token aleatorio.Dado que se trata de un campo de contraseña, el usuario no podrá saber (a excepción de la longitud). Luego, almacene la contraseña y el token hash en la sesión. Cuando el usuario envía el formulario, si el campo de contraseña es el mismo que el token almacenado, use el hash de contraseña almacenado. De lo contrario, use la contraseña presentada. Esto resuelve los problemas de caché (dado que el token aleatorio no tendrá significado en las solicitudes de otras sesiones). De esta forma, nunca necesitará almacenar o transmitir la contraseña sin procesar después del envío del formulario inicial ...

Answer 2

Volver a llenarlo es mucho más cómodo para el usuario.

Sin embargo, si el formulario se envía de forma clásica (es decir, con una recarga de página completa, no a través de AJAX), corre el riesgo de que el html que contiene la contraseña se guarde en caché. Sin embargo, con los encabezados adecuados puedes reducir/eliminar ese riesgo. Usar HTTPs también es realmente importante en ese caso. Impide por completo que los proxies HTTP lo almacenen en caché y que el caché local del navegador generalmente respeta los encabezados de nocache (y aunque no sea así, no es un gran problema si el caché ocurre en el equipo local).

En general, prefiero no tener que ingresar la contraseña nuevamente porque otro campo (por ejemplo, un captcha de mierda) era incorregible ... pero en un entorno de alta seguridad no quiere volver a llenar la contraseña campo a menos que esté utilizando AJAX y no tenga que devolver la contraseña introducida.

Answer 3

Absolutamente, borre los campos de su contraseña y no vuelva a llenarlos. No comprometa la seguridad para la usabilidad.

Answer 4

Es un problema de seguridad en las computadoras compartidas, ya que la contraseña será visible en texto sin formato al visualizar la fuente html. No solo en una ventana activa del navegador, sino también en cualquier caché basada en disco.

Yo personalmente iría con OpenID en lugar de requerir que el usuario invente otro par de nombre de usuario + contraseña para recordar (que también afectan a la usabilidad para mejor).

Answer 5

Si necesita enviar la contraseña real (o cualquier cosa derivada de ella) del servidor al cliente para volver a llenarla, es un importante agujero de seguridad.

Si todo lo que hace es guardar la contraseña localmente en el cliente hasta que el formulario presente la validación (al no volver a cargar la página, por ejemplo, mediante javascript), entonces me parece bien.

Answer 6

No, no lo hará (si se hace bien).

• Un atacante en la red (es decir, entre el navegador y el servidor) habrá visto la contraseña que el cliente envió. Si usa HTTPS, debe usar para el formulario y su destino.
• Un atacante del lado del navegador podría haber registrado un detector en el campo de contraseña o interceptado la solicitud.
• Un tercero atacante podría intentar recuperar la página completada de un proxy que el usuario está usando. Establezca los encabezados apropiados Cache-Control para evitar que la página se guarde en caché.