¿Los enlaces de restablecimiento de contraseña que no expiran son un riesgo para la seguridad?

Por ejemplo: si recuerdo mi contraseña, no la restablezca.

Ahora, si mi cuenta de correo electrónico se ve comprometida más tarde (o si visito el enlace y alguien decide leer detenidamente mi historial de navegación), pueden cambiar mi contraseña a voluntad y no hay forma de evitarlo excepto para cambiar mi propia contraseña.

A menos que, por supuesto, quisieras decir que el token solo sirve para una visita de una página. Eso es seguro, pero también inconveniente si cierro la página, caduca mi sesión, etc.

Además de los escenarios que se han mencionado en otras respuestas, la principal razón que pude ver para tener enlaces de restablecimiento de contraseña caducados es que el enlace podría guardarse en caché o almacenarse en una variedad de ubicaciones y eso podría (en ciertas circunstancias) Permitir que otra persona tenga acceso a la cuenta de los usuarios.

• Historial del navegador. Este parece más probable como un riesgo. El usuario restablece una contraseña de una PC compartida. Espero que el enlace ingrese el historial del navegador, de modo que cualquier persona que pueda acceder a ese navegador pueda restablecer la contraseña de los usuarios y tomar el control de la cuenta.
• En caché por un servidor proxy. Obviamente, si tiene HTTPS, la mayoría de los proxies no verán el enlace; sin embargo, en muchas corporaciones, se utiliza la intercepción SSL, por lo que esos proxies almacenarán el enlace en la memoria caché y también IIRC.
• Añadido a favoritos. El usuario sigue el enlace, cree que "esto es útil" lo agrega a los favoritos, ahora cualquiera que use ese navegador tiene acceso a su cuenta. No es particularmente probable pero es posible.

Si estos escenarios son importantes para usted, dependerá de sus casos de uso y del nivel de seguridad que desee proporcionar.

Eso es correcto. La caducidad de estos tokens es mucho más segura ya que un atacante con acceso a su base de datos podrá obtener estos tokens y usarlos para restablecer a los usuarios que solicitan un restablecimiento de la contraseña pero no completan su solicitud.

También debería mencionar: tratar los tokens de restablecimiento de contraseña como un gran secreto como las contraseñas. Es decir, no los almacena en texto sin formato, los genera, los envía al usuario y los almacena en su base de datos. Eso también evita que los atacantes con acceso de lectura solo lean y abusen de los tokens.

OWASP tiene una excelente hoja de trucos para restablecer la contraseña , su argumento sobre el período de validez limitada es como @Jonathan Newmuis dijo que:

  

[...] si el usuario no comprueba su correo electrónico y su cuenta de correo electrónico se ve comprometida posteriormente, el token aleatorio utilizado para restablecer la contraseña ya no será válido si el usuario nunca restablece su contraseña y El token de "restablecer contraseña" fue descubierto por un atacante. Por supuesto, una vez que se haya restablecido la contraseña de un usuario, el token generado aleatoriamente ya no será válido.

Punto tomado acerca de cómo un compromiso de la cuenta de correo electrónico que recibe el token niega algunos de los beneficios de caducar el token. Sigo pensando que la caducidad del token tiene cierto valor, según Jonathan Newmuis.

Escenario:

1. Solicito un restablecimiento de mi cuenta en ACME, que se envía por correo electrónico a mi buzón en Big Kahuna Corp.
2. Recuerdo mi contraseña de ACME y no uso el token de restablecimiento.
3. Algún tiempo después, cambio a Gmail, pero dejo mi cuenta de Big Kahuna por ahí.
4. En algún momento después de eso, mi buzón de Big Kahuna está comprometido.

Escenario A: Sin caducidad

5b. El atacante encuentra el token de restablecimiento de ACME y lo utiliza para comprometer mi cuenta de ACME.

Secnario B: Caducidad después de N días

5b. El atacante encuentra el token de restablecimiento de ACME que ha caducado , pero ahora sabe que tengo una cuenta de ACME. Él vuelve a emitir el token de restablecimiento de ACME, y como he cambiado a Gmail (y cambié mi dirección de restablecimiento en consecuencia en el sitio web de ACME), el token de restablecimiento va a Gmail, evitando una violación y indicándome que estoy bajo ataque.

Sí, el ejemplo está diseñado, pero es completamente plausible.

Quizás un buen punto intermedio es tener una lista de tokens de restablecimiento "válidos actualmente" que el usuario muestre al iniciar sesión, y que tenga la oportunidad de revocarlos.

El mayor problema es que no desea almacenar el token de restablecimiento de contraseña en la base de datos en texto sin cifrar. Esto produce un acceso directo, donde el atacante no tiene que descifrar el hash de la contraseña, solo puede restablecer la contraseña. Almacenar un hash del token de restablecimiento de contraseña es una buena solución para este problema.

Es una buena idea que el token de restablecimiento de contraseña caduque y que solo se use una vez. Sin embargo, esto no es tan importante como almacenar estos tokens en texto sin formato. La razón más importante para que el token expire es hacer que sea más difícil para el atacante adivinar este valor. Si el atacante tiene acceso al correo electrónico del usuario, puede enviar otro token, que es un punto discutible.

Puedo pensar en algunas razones para limitar la validez:

1. Defensa en profundidad: está proporcionando un token valioso y sensible, ya que este token se puede usar para obtener acceso a una cuenta. No sabe exactamente qué va a hacer el usuario con el enlace, qué hace su proveedor de correo electrónico; lo que los proxies web hacen con los enlaces visitados; si se trata de una cuenta de correo electrónico de grupo frente a una cuenta individual, etc. (Otros respondedores han dado varios escenarios). Limite la validez del token para limitar el daño potencial.

2. Ataques de enumeración: si puedo hacer que se genere un token (por ejemplo, al hacer clic en el botón "Olvidé mi contraseña"), incluso si no puedo acceder a ese token, puedo intentarlo. para enumerarlo. Al limitar la validez del token, limita la cantidad de tiempo que tengo para adivinar correctamente.

La caducidad ofrece una protección adicional, pero como señala en sus comentarios, un atacante que tiene acceso a la cuenta de correo electrónico puede simplemente solicitar un nuevo token. ¡No importa si el usuario legítimo ya no accede a la cuenta de correo electrónico (según lo señalado por OWASP), el atacante sí!

Un enfoque mucho mejor es pedirle al usuario información adicional durante la fase de validación del token, información que nunca se envía por correo electrónico. Por ejemplo, "cuál es el apellido de soltera de tu madre".

Alternativamente, puede pedirle al usuario esta información durante la fase de "solicitud de nuevo enlace de contraseña" y luego establecer una variable de sesión / cookie de tiempo limitado que indique que la información es correcta. Cuando el usuario hace clic en el enlace del correo electrónico, también verifica esta cookie. En cierto modo, es un poco menos seguro porque si el atacante tiene acceso al navegador (o las cookies) todavía puede restablecer la contraseña si es lo suficientemente rápido. Sin embargo, esta estrategia tiene la ventaja de evitar correos electrónicos no deseados, ya que el usuario debe comprobarse antes de que incluso envíe el correo electrónico de restablecimiento.