Requerir el mismo ID de sesión a través de todos los pasos del proceso de restablecimiento de contraseña

EDITAR: dos respuestas a continuación.

Respuesta original

Puede insertar otra ID en el enlace que hace un seguimiento de la ID de la sesión original.

¿El requisito de que el enlace del correo electrónico, cuando se hace clic en él, se inicie en el mismo navegador o puede estar en un navegador diferente? ¿Y si está en una máquina diferente? Por ejemplo, ¿qué sucede si restablezco la contraseña de mi teléfono y luego me muevo a mi computadora o tableta, hago clic en el enlace del correo electrónico y configuro una nueva contraseña? Podría hacer esto si quiero usar el almacén de contraseñas en mi computadora aunque empecé en mi teléfono. Desde la perspectiva de la facilidad de uso, parece que el enlace de la contraseña en el correo electrónico y no el ID de sesión del navegador original es importante.

Además, si un atacante hizo clic en el enlace "Olvidó la contraseña" y trató de obtener la entrada y obliga a que el ID de sesión sea el mismo, entonces el usuario real que recibe el enlace para restablecer la contraseña podría experimenta un DOS dependiendo de cómo funciona tu sistema. Ciertamente, el usuario legítimo no puede restablecer su propia contraseña con el enlace proporcionado porque la ID de la sesión que originó la solicitud "Olvidé mi contraseña" reside en el navegador de los atacantes.

Como desarrollador de aplicaciones, debería poder realizar una de las siguientes acciones:

1. Reconocer una segunda sesión iniciada desde el enlace de restablecimiento de contraseña como legítima y dejarla pasar.
2. Procese el enlace de restablecimiento y vuelva a establecerlo con el primer ID de sesión.

Sin embargo, realmente creo que el # 2 está mal aconsejado dado que un atacante podría estar haciendo clic en el enlace Olvidé mi contraseña. Creo que lo mejor es usar la segunda sesión.

Por cierto, los sistemas más paranoicos que he visto obligan a volver a iniciar sesión una vez que se ha restablecido la contraseña. Es decir, hace clic en "Olvidé mi contraseña", recibe el correo electrónico, hace clic en el enlace, restablece la contraseña, luego aparece una nueva página de inicio de sesión que requiere que ingrese su nombre de usuario y una nueva contraseña (en lugar de iniciar sesión silenciosamente como consecuencia del restablecimiento de la contraseña).

Segunda respuesta: aclaración en los comentarios de la pregunta

Parece que está preocupado por el artículo de OWASP al que se hace referencia. En este caso, el artículo recomienda realizar una sesión continua para restablecer la contraseña y usar un canal alternativo o fuera de banda (OOB) para aumentar la probabilidad de que esté hablando con el usuario legítimo. En este caso, el usuario inicia el proceso de restablecimiento de la contraseña, responde correctamente a las preguntas de seguridad, está bloqueado de la cuenta , se envía un código OOB PIN por SMS o correo electrónico (nota, no un enlace de restablecimiento), el usuario ingresa el código PIN correcto, luego se puede ingresar una nueva contraseña.

Esto no era lo que contenía la pregunta original. En este caso, un enlace para restablecer la contraseña es no para ser enviado y solo un código PIN para ser visto con un lector de correo electrónico e ingresado en el mismo flujo de sesión de restablecimiento de contraseña. Saltar a una nueva ID de sesión (incluso si es posible) debería verse como un ataque o error del sistema y rechazarse.

Realmente tengo que estar en desacuerdo con las otras respuestas, cuando respondo a la pregunta tal como se me hizo.

Primero, supongamos que el atacante conoce su dirección de correo electrónico y tiene una forma de leer el correo electrónico de restablecimiento que se le envió.

Si el atacante puede leer el correo electrónico que se te envía, es casi seguro que sabe cuál es tu dirección de correo electrónico. También dijo que todo lo que necesita para generar el correo electrónico de restablecimiento de contraseña es su correo electrónico (que acabamos de decir que tiene).

Esto significa que, ya sea:

• No puede leer su correo electrónico, por lo que su token de restablecimiento de contraseña está a salvo de él (por lo que no necesita que sea la misma sesión)
• Puede leer su correo electrónico y, por lo tanto, probablemente sepa su dirección. Esto significa que él puede hacer clic en el enlace para restablecer la contraseña y generar una nueva contraseña.

Ahora hay casos de esquina:

• El atacante cree que el segundo correo electrónico podría revelar al propietario de la cuenta que la cuenta está en peligro, y no puede eliminar el correo electrónico de la bandeja de entrada
• El atacante puede leer el correo electrónico de alguna manera sin saber realmente su dirección de correo electrónico

Sin embargo, en general, creo que esos casos son bastante improbables y mucho menos importantes que el problema de la usabilidad. Aquí hay tres ejemplos:

• Estoy navegando en mi tableta, pero olvide mi contraseña. Hago clic en "Olvidé mi contraseña" y luego uso el correo electrónico en mi escritorio. Ahora su recuperación de contraseña falló. Espero que tengas un mensaje de error realmente bueno, o creo que tu sitio está dañado.
• Estoy navegando en Chrome y hago clic en "Olvidé mi contraseña". I alt-tab en otro navegador donde estoy conectado a la otra cuenta de correo electrónico a la que está vinculada esta cuenta. Hago clic en el enlace de restablecimiento, y nuevamente falló.
• Estoy en una pestaña privada y hago clic en Olvidé mi contraseña. Veo el mensaje en mi cliente de correo y hago clic en el enlace, abriendo el enlace con el navegador predeterminado del sistema. Una vez más, el fracaso.

Creo que los problemas de UX son mucho más importantes que cualquier pequeña mejora de seguridad que obtendrías al requerir esto.

Donde esto podría ser más útil es si "Olvidé mi contraseña" requiere más que un correo electrónico. Si el envío del correo electrónico de restablecimiento requiere una respuesta a una pregunta de seguridad, esto podría ser útil. De lo contrario es probable que sea simplemente molesto.

Al igual que con la mayoría de los artículos de OWASP, no siempre se explica el razonamiento detrás de algunos de los pasos de implementación sugeridos, lo que permite a los lectores adivinar cuáles son las ventajas y los riesgos de no tener en cuenta todas las recomendaciones. Algunos de ellos pueden ignorarse de manera segura, mientras que otros son críticos para mitigar el riesgo original. Le sugiero que siempre use OWASP como un buen punto de partida y luego intente averiguar si la solución completa es realmente necesaria (como ya lo ha hecho).

  

¿Es eso algo factible de requerir? ¿Hay algún "caso de uso normal"?   ¿Dónde no funcionaría el mismo ID de sesión?

Ignorando la implementación en el artículo de OWASP y hablando en general sobre los mecanismos de restablecimiento de contraseñas, el requisito de permitir solo restablecimientos desde la misma sesión evita que un token dropper intercepte y use un token de restablecimiento de contraseña enviado por correo electrónico. Digamos que un atacante ha configurado una regla de reenvío de correo para que obtengan una copia de cada correo electrónico enviado a una cuenta. Tenga en cuenta que esto solo se aplica si se combina con preguntas de seguridad (que tienen sus propios problemas). De lo contrario, un atacante podría solicitar el restablecimiento directamente y luego seguir el enlace desde su propia sesión.

Esto también funcionaría con tokens de restablecimiento de SMS, donde un atacante logró colocar malware en el teléfono de la víctima para leer los mensajes, o pudo clonar su SIM para recibir SMS dirigidos a la víctima.

No funcionaría con algunos mecanismos de restablecimiento de contraseña fuera del límite, como el envío de un token de restablecimiento a través de correo postal a menos que este identificador de sesión persista durante un período prolongado de tiempo (esto podría lograrse de manera segura a través de un token de cookie adicional , no relacionado con la sesión real iniciada en la sesión).

Al final del día, la decisión de usar dicho mecanismo depende de la propensión al riesgo de su sitio y su "nivel de seguridad". En esencia, se requiere el uso exacto del mismo navegador para completar el proceso de restablecimiento de contraseña (descontando la fijación de sesión o los ataques de robo de sesión). Tiene limitaciones, como el hecho de no permitir que se active un reinicio activado desde un navegador móvil en una PC. En ese caso, la restricción podría ser relajada para requerir la misma IP, sin embargo, esto no ofrece protección cuando el atacante está en la misma red, o en el caso de que se utilicen proxies ISP compartidos (por ejemplo, proveedores de AOL, 3 / 4G).