Restablecer la contraseña de ASP.NET: ¿problemas de seguridad?

He visto varias preguntas sobre este tema, pero hay un par de preguntas que no se han formulado. Si el usuario olvida su contraseña, me gustaría que puedan restablecerla solo con su dirección de correo electrónico (es decir, no hay preguntas/respuestas de seguridad). La contraseña se almacena como un hash salado, por lo que no hay recuperación posible. En cambio, me gustaría que el usuario ingrese una nueva contraseña después de confirmar que ha solicitado un restablecimiento.Restablecer la contraseña de ASP.NET: ¿problemas de seguridad?

Un método común que se ha mencionado es simplemente:

1) Crear un GUID/criptográficamente segura aleatoria de números aleatorios

2) Enviar una URL única que contiene el número aleatorio de correo electrónico del usuario abordar

3) Cuando se confirma, se le pide al usuario a cambiar la contraseña

Sin embargo, ¿no está esto abierto a un ataque MITM? Si el envío de contraseñas temporales a través de Internet a un correo electrónico es inseguro, ¿cuál es la diferencia entre hacer eso y simplemente enviar una URL única a la que el atacante pueda navegar? ¿He perdido un paso clave en alguna parte que hará que este sistema sea más seguro (o existe una forma mejor de restablecer la contraseña)?

Gracias

Fuente

2010-01-27 keyboardP

Si construye su picadillo correctamente, la URL tendrá que venir de la dirección IP que ha solicitado el reinicio. Esto requeriría que el MITM falsificara el IP y/o falsificara los encabezados. Si bien esto es posible, cuanto más único pueda identificar el hash para el sistema en cuestión, más difícil será "finalizar" el hash.

También se recomienda que el guid sea un hash unidireccional de ciertos criterios. También es posible encriptar los datos del sistema en la solicitud usando una clave pública que una clave privada desbloquea para que cuando se haga clic en la url, estos mismos datos públicos del sistema encriptados deben acompañar al hash, y el único sistema que podría descifrar estos valores sería la clave privada en el servidor. Básicamente un archivo adjunto psuedo-PKI al hash.

Fuente

2010-01-27 22:59:02

me gusta la idea de tratar de asegurar el enlace de clic de confirmación viene del mismo equipo que el inicial solicitud de restablecimiento –

En cuanto al aspecto de IP, ¿seguramente esa parte sería irrelevante? Como atacante, yo diría que olvidé la contraseña yo mismo, por lo tanto, la solicitud de restablecimiento de contraseña proviene de mi (el atacante) PC. Al realizar un ataque MITM, interceptaría el correo electrónico, haré clic en el enlace y cambiaré la contraseña, ya que sigue viendo mi dirección IP. – keyboardP

Posiblemente, pero esto supone que el atacante ya ha comprometido la cuenta de correo electrónico también. La IP solo sería un pequeño subconjunto de información de identificación. Podría haber otras métricas aplicadas que aumentarían la complejidad del hash. La clave sería no depender de ninguna métrica ya que cada una debe estar comprometida. Cuanto más se requiera, más difícil será pasar. En un punto, se convierte en una cuestión de esfuerzo vs. resultado. –

Sus medios para autenticar al usuario son un secreto compartido (la contraseña).

Si el usuario olvida ese secreto, necesita una forma de establecer un nuevo secreto compartido. Independientemente de la forma en que lo haga, seguirá teniendo el problema de autenticar al usuario para compartir ese nuevo secreto.

Si lo único que sabe sobre el usuario que podría utilizarse para autenticarlos es su dirección de correo electrónico, entonces necesitará alguna forma de confirmar que el usuario que solicita un restablecimiento tiene el control de esa dirección de correo electrónico.

Y la única forma de hacerlo es enviar un correo electrónico con un secreto a esa dirección de correo electrónico y verificar si lo recibió.

Que siempre estará abierto a un ataque MitM suficientemente furtivo.

El motivo por el que no envía una contraseña temporal es evitar el problema de "no se puede cambiar el usuario y, por lo tanto, se sigue utilizando la contraseña temporal insegura en lugar de la segura."

Fuente

2010-01-27 22:59:18

De acuerdo con todo lo anterior. Solo agregaría que una contraseña temporal debe ser de un solo uso: una vez que se usa para iniciar sesión en el usuario, no se puede usar nuevamente y el usuario debe cambiarla, de lo contrario, el usuario tendría que solicitar una nueva contraseña. No evita el ataque de MITM de ninguna manera, pero debería ayudar hasta cierto punto. – JonoW

La ironía de la contraseña temporal es que probablemente sea más segura que la contraseña real del usuario: D Sin embargo, voy por la ruta del 'enlace de confirmación' que los bloquea hasta que se cambie la contraseña. – keyboardP

Con el vector de ataque MITM. Sería negado si al solicitar una nueva contraseña se le envía un secreto. Luego, cuando se le envíe el enlace del correo electrónico y haga clic en el enlace, ¿tiene que ingresar ese mismo secreto nuevamente? –

para mitigar el riesgo de un hombre en medio del ataque utilizo las siguientes medidas:.

Una solicitud de restablecimiento puede ser utilizado sólo una vez
Si una solicitud de reposición no se utiliza, se expira después de una hora.
Todas las solicitudes de restablecimiento se registran de forma permanente si se ha completado o en última instancia, expiró.

Fuente

2010-01-28 01:02:33

Me gustaría hacer que el restablecimiento expire mucho más rápido que una hora. El intento de restablecer una contraseña es de acceso inmediato. No es razonable esperar que un usuario "honesto" espere una hora para usar el restablecimiento. –

Restablecer la contraseña de ASP.NET: ¿problemas de seguridad?

Respuesta

Cuestiones relacionadas