En los sistemas múltiples que he construido / soportado, he visto a la administración de usuarios hacer lo siguiente para restablecer la contraseña: generó un token de restablecimiento de contraseña a través de algún método de hashing y envía por correo electrónico el enlace con el token al usuario. Por lo general, se incluye información sobre estos tokens: identificación de usuario, sello de seguridad del usuario, fecha, nombre del servidor o clave de la máquina (ahora voy con el marco de identidad de ASP.Net). Cuando el usuario sigue el enlace con el token, framework sigue el mismo proceso para reconstruir el token y compara el token con el proporcionado por el usuario. Si los tokens coinciden: permite restablecer la contraseña.
Muchas partes del token de tiempo relacionadas con la máquina cambian desde el momento de la generación del token hasta el momento en que el usuario usa ese token. Es decir. IIS se reinicia y esto puede invalidar el token en algunos casos. Cuando la aplicación web se distribuye en varios servidores (es decir, la granja de servidores web), las posibilidades de que este token no sea válido son mayores (es decir, las claves de la máquina no están sincronizadas entre las máquinas, etc.).
Ahora estoy considerando un escenario donde almaceno el token generado en la base de datos, agregue una marca de tiempo de generación. Y cuando el usuario regresa con el token, no vuelvo a generar el token, sino que comparo el token almacenado, validar la marca de tiempo y permitir / deshabilitar el restablecimiento de contraseña.
Dado que el token ahora se convierte en una contraseña (aunque por tiempo limitado), por una buena medida puedo tratarlo como contraseña y almacenar hash solamente.
No puedo pensar en fallas en este escenario, pero estoy seguro de que hay algunas. Dado que la implementación de este escenario es sólida, ¿qué otros problemas podrían surgir al almacenar los tokens?