The constant time comparison is pretty irrelevant here. Check https://github.com/haiwen/seahub/commit/7cdb70368aa7acbf0546..., basically a valid password reset token in default Django requires an attacker to know:
- Primary Key of the user (User ID)
- Hashed version of the user password
- Timestamp of the last login (1 second accuracy)
- Number of days since 2001-1-1 converted to base 36
- The configured SECRET_KEY
Basically except the configured SECRET_KEY and the hashed version of the password everything is known to an attacker. And even if an attacker knows the SECRET_KEY they would not be able to generate a valid token as the old password hash is required.
However, Seafile has removed the hashed password out of their version of "tokens.py". This means that if somebody knows the SECRET_KEY they could create valid password reset tokens. That the initial SECRET_KEY was basically generated by `str(random.randint(0,100000))` did make this all much more worse… (https://github.com/haiwen/seahub/blob/b6f8935c0f355cc70145f9...)
Bad thing about this is that this basically makes a lot of old Seafile instances insecure unless they get a new SECRET_KEY. They did somewhat tell users to regenerate it within a forum post and some wiki page (https://seacloud.cc/group/3/wiki/whats-new-in-the-next-versi...) but that's not really a good way to spread awareness…