¿Debería caducar el enlace de restablecimiento de contraseña al hacer clic, o esperar hasta que se complete y complete el restablecimiento?

3

Im implementando una solución de recuperación de contraseña que sigue esta convención de marco genérico:

enlace

Mis preguntas son cuándo debería destruirse el token de reinicio. Según el frameowrk, "El token de reinicio debe ser invalidado tan pronto como se use ".

Significa:

  1. para destruir tan pronto como el usuario llegue a la página web para ingresar una nueva contraseña
  2. para destruir cuando llamamos a la API para restablecerla con la nueva contraseña

La primera opción significa que el usuario no puede actualizar / golpear la página dos veces porque destruirá el token en el primer aterrizaje. La segunda opción permite al usuario acceder a la página tantas veces como lo desee, ya que se proporciona la validación del token con una nueva contraseña. Sin embargo, podríamos ir más allá y validar el token de recuperación cuando el cliente acceda a la página web, pero destruirlo solo cuando se proporcione una nueva contraseña.

¿Podría por favor echarme una mano sobre esto?

Nota: el enlace para restablecer la contraseña se proporciona por correo electrónico.

    
pregunta Roberto14 02.11.2016 - 16:42
fuente

3 respuestas

3

No veo un problema con el # 2 y ciertamente es más fácil de usar, siempre que la página de reinicio solo esté disponible a través de https (de modo que no se pueda mitigar y alguien no pueda colarse más rápido) ).

No veo un vector para explotar # 2 que no esté allí para # 1.

    
respondido por el crovers 02.11.2016 - 16:50
fuente
2

Con "usado", por supuesto, significaron cuando se envió el restablecimiento de la contraseña. No cuando se hizo clic en el enlace. De lo contrario, dirían "Destruir el token cuando se haga clic en el enlace "

Sería un proceso muy engorroso si el usuario hace clic en el enlace y luego ingresa una contraseña que no cumple con sus reglas de contraseña ... Vaya enlace invalidado, ahora el usuario debe comenzar desde el principio.

Existe el riesgo de que el token de restablecimiento de la contraseña real sea robado en tránsito en la carga de la página, y luego se use antes de que el usuario envíe el restablecimiento de la contraseña. Pero este riesgo se puede mitigar al no incluir el token de restablecimiento dentro del enlace. En su lugar, tiene dos enlaces en su página de inicio de sesión: Contraseña olvidada, que enviará por correo electrónico el token. El correo electrónico no contiene ningún enlace.

Y luego restablecer la contraseña, que proporcionará un formulario que solicita el nombre de usuario, la nueva contraseña, la contraseña de confirmación y el token.

Luego, el usuario debe ingresar el token del correo electrónico manualmente en lugar de incluirlo en el enlace, evitando así la posibilidad de oler el token y luego usarlo antes que el usuario real. Porque entonces el adversario tiene que bloquear para que la solicitud real nunca llegue.

    
respondido por el sebastian nielsen 03.11.2016 - 09:25
fuente
0

Estoy de acuerdo con @crovers. Otro truco sería poner un temporizador en el enlace, por ejemplo, 30 minutos. Fácil de hacer, es poco probable que afecte a usuarios válidos, pero hace la vida más difícil para cualquiera que procesa un gran volcado de tráfico.

    
respondido por el Hadog 02.11.2016 - 20:29
fuente

Lea otras preguntas en las etiquetas