Devolución de una contraseña para el usuario de la web

Question

He recibido el desafortunado requisito de la construcción de una página que muestra una nueva contraseña para el usuario autenticado. He protestado, sin éxito, este requisito como generalmente mala idea, pero creo que el jurado aún así que quizás hay argumentos en contra de mostrar una nueva contraseña que no he probado todavía. ¿Tiene alguna sugerencia?

En segundo lugar, sería mejor para mostrar la contraseña para el usuario como una imagen, en lugar de como texto. Estoy preocupado por el texto que se está "raspado", que estoy suponiendo que sería más difícil con una imagen. ¿Cómo me aseguro de que la imagen no se almacenan en caché por el navegador de los usuarios?

Gracias de antemano,

Answer 1

No estoy seguro de lo que está y lo que es construir los requisitos, pero como regla general no considero esto un problema de seguridad grave. Veamos los vectores de ataque:

1. el hombre en medio del ataque en el texto tráfico HTTP -. Una imagen, especialmente uno contra ofuscado (estilo de CAPTCHA) OCR impedirá que este ataque, sino también el simple uso de HTTPS como se ha mencionado porneL
2. Pantalla raspado por una aplicación de escritorio remoto - HTTPS protección no ayudará, ni una imagen como el desorden en una pantalla tiene que ser leído por un humano de todos modos (un atacante humano también puede eludir su protección de la imagen ofuscado contra el "hombre de la medio", instruyendo al oyente a archivar la imagen y luego ir sobre ellos de forma manual). Si un ser humano está detrás del raspador de pantalla, entonces no tiene protección.
3. por encima de su hombro espionaje - si el atacante es simplemente de pie detrás del usuario, y de nuevo -. No tiene protección

Ten en cuenta que si se genera automáticamente su contraseña, entonces debe mostrar al usuario, no hay forma de evitar eso. Uno sitios manera tratan de mitigar la amenaza es enviar la contraseña por correo electrónico - en el supuesto de que un usuario puede asegurarse de que leen el correo electrónico cuando nadie está mirando, a su propio tiempo. Desafortunadamente correo electrónico no será ni siquiera le permiten tener el beneficio de cifrado para proteger la transferencia.

En mi opinión, la mejor manera es dejar que la entrada del usuario la contraseña (en un campo de contraseña de ofuscación, como normalmente se hace) y sólo almacenar el hash de la contraseña de manera que no es necesario almacenar la contraseña real, evitando que a partir de mostrarlo al usuario. Si tiene que mostrar al usuario (posiblemente debido a que se está generando), entonces asegúrese de que está a través de HTTPS y simplemente mostrar que -. Toda la fanfarria simplemente complica la aplicación sin dar ningún beneficio de seguridad

Answer 2

Imagen no asegurará mucho.

Si utiliza HTTPS, a continuación, la contraseña será segura de cualquier manera. Si utiliza HTTP, contraseña será enviada en texto claro de la forma (supongo que se esté viendo por algún tipo de confirmación), y cómo se visualiza segundos más tarde no tendrá importancia.

Lo importante es asegurarse de que la página que muestra la contraseña no es cache'able.

Cache-control: no-cache, no-store, must-revalidate

Answer 3

¿trató el siguiente?

• no se puede mostrar la contraseña, ya que no lo almacena.

Answer 4

No estoy seguro de si es realmente una mala idea. Usted tiene que enviar la nueva contraseña para el usuario, ya sea en forma. El envío de correo electrónico como no cifrado tiene los mismos problemas -. Beeing capturado o beeing en caché cuando se utiliza el correo web

Yo sugeriría utilizar una imagen, puede haber algún código de imagen como tal. Pero esto sólo protege un poco más contra ataques automatizados, no contra los ataques humanos.

La única manera de conseguir la cosa segura es utilizar enryption, lo que sugiere HTTPS. Luego, utilizando su sitio web para mostrar puede llegar a ser incluso más seguro que confiar en las soluciones de correo electrónico o por el estilo.

Leting el usuario introduzca una nueva contraseña tiene el mismo problema - ahora usted tiene que enviar de vuelta al servidor

.

Answer 5

Yo simplemente sugerir el uso de HTTPS para cifrar el tráfico y almacenar sólo hashes de contraseñas temporales, por lo que la contraseña real no se almacena dentro de la base de datos. Por supuesto, no se puede evitar que los "hackers" físicos (tales como personas que buscan detrás del hombro) desde el robo de una contraseña temporal, pero, si es posible, se puede exigir a los usuarios a cambiar su contraseña en el instante en que se conecten con una contraseña temporal, de manera que los riesgos con una contraseña temporal se mitigan.