Usando el hash de la contraseña como token de restablecimiento

Hay un par de desventajas con este esquema:

1. Como han señalado otras respuestas, esto filtra el hash de contraseña del usuario. Este es un problema no porque el usuario legítimo lo entiende o porque cualquier persona con acceso al correo electrónico podría ser la propietaria de la cuenta (esto también se aplica a los tokens de reinicio) pero porque permite que un atacante pueda leer el Correo electrónico para realizar un ataque de diccionario en el hash. Es probable que el usuario establezca su nueva contraseña en algo muy similar o que haya reutilizado la misma contraseña en varios sitios. Fugas de hashes no son deseables, incluso si están saladas correctamente & hash En consecuencia, si el atacante alguna vez está comprometido por un atacante, tiene valor para el atacante.
2. También, como se señaló, esto hace que sea difícil regenerar el token o hacer que caduque. Los tokens para restablecer la contraseña no deben ser válidos indefinidamente en caso de que alguien tenga acceso a una copia antigua del correo electrónico (por ejemplo, una copia de seguridad) o lo haya retirado del servicio pero no lo use de manera oportuna. Su "beneficio" de no expirar el token es en realidad un inconveniente desde el punto de vista de la seguridad. (Y marginalmente útil desde el punto de vista de la usabilidad).
3. En el correo electrónico de restablecimiento, el token se coloca a menudo (¿siempre?) como un parámetro de cadena de consulta. Esto significa que el token (y el hash de la contraseña del usuario) se almacenarán en el historial de su navegador, y probablemente en cualquier registro del servidor web.

Esta es una muy mala idea.

Está asumiendo que nadie excepto el usuario tiene acceso a sus correos electrónicos. En ese caso, ¿por qué no simplemente enviarles su contraseña de texto simple?

En realidad, debemos suponer que otros pueden tener acceso a los correos.

Si asumimos eso, hay varios problemas con su enfoque. Un atacante puede romper el hash y obtener la contraseña. Ahora pueden:

• Inicia sesión en sin restablecer la contraseña. Esto significa que el usuario no será consciente del hecho de que su cuenta fue tomada.
• Pruebe la contraseña, y sus variaciones, en otros servicios (los usuarios reutilizan las contraseñas).

  

Esto podría tener algunos beneficios, como la ausencia de tiempo de caducidad en el correo electrónico de restablecimiento

Eso no es realmente una característica, es un error .

El propósito de usar un token de restablecimiento de contraseña no es solo crear una dirección indirecta o un secreto compartido para restablecer las contraseñas. Puede crear características de seguridad adicionales, como la caducidad del token o el uso limitado.

También es inseguro enviar hashes de contraseña del usuario. Por lo general, cualquier usuario no autenticado tiene permitido restablecer la contraseña en una cuenta. Al solicitar el restablecimiento de la contraseña en una cuenta, un adversario podría realizar un ataque de tabla / arco iris en el hash de contraseña obtenido. Esencialmente, la seguridad de la contraseña y el sistema se debilitan significativamente.

El uso del hash de contraseña almacenado para restablecer la contraseña puede funcionar funcionalmente para restablecer la contraseña, ya que de hecho es un secreto compartido entre el servidor y el usuario. No es una solución duradera.

Considere una situación en la que un atacante obtiene una copia de su base de datos de contraseñas cifradas (lamentablemente una ocurrencia muy común ). Un atacante así podría usar estas contraseñas con hash para restablecer la contraseña para todos sus usuarios.

Los sistemas que usan tokens de restablecimiento de contraseñas y almacenan tokens hash en su base de datos de tal manera que no sería posible un ataque.

suspiro no inventes una nueva contraseña / hash / esquemas de token.

Su esquema tendría la desventaja de permitir que un atacante obtenga información sobre la sal que utiliza para cifrar las contraseñas. Básicamente es un habilitador para los ataques de texto plano conocido.

Eso básicamente debilita la ventaja de almacenar hashes en lugar de contraseñas.

Además, esto permitiría que alguien que solo pudiera leer sus correos electrónicos siempre se diera cuenta cuando cambia su contraseña.

Además, esto significa que el token de restablecimiento de contraseña nunca caduca. no hay ningún mecanismo para simplemente invalidar un token si se ha filtrado. También significa que una parte malintencionada puede esperar hasta que se vaya de vacaciones para cambiar su contraseña, en un momento en el que no pueda notarlo (y no lo notará, porque el token permanece igual mientras no cambie) su contraseña, por lo que no es necesario un nuevo correo electrónico de restablecimiento).

Además, esto tiene la ventaja marginal de que solo le permite guardar una entrada limitada por vida en cada solicitud de restablecimiento de contraseña en una tabla. No veo el beneficio de hacer eso.

No trates de ser más inteligente que los millones de personas que están construyendo autorizaciones de última generación.