Password Reset exposes non-trivial security vulnerability

[fergusferrier]

Assuming an attacker obtained:
1) read access to your Users table
2) read access to your settings.py file [presumably a good chance of this if they have 1)]

Then they can set the password for any user, because the token that would have been created in password reset can be created knowing settings.SECRET_KEY and the User's data.

        hash = sha_constructor(settings.SECRET_KEY + unicode(user.id) +
                               user.password + unicode(user.last_login) +
                               unicode(timestamp)).hexdigest()[::2]

Thus escalating read-access to certain data, to User-level write access. Or if a superuser account were compromised, full data-object-level write access.

Two alternatives:

1) A randomly-generated key is generated each time password reset requested, and stored in a Model. This only restricts the vulnerability to attackers who have real-time access to the User table, as they can effect the same vulnerability by requesting password reset for the user they wanted to 'become', and reading the key from the database. Though this leaves password reset emails in wake.

2) The only possible better idea I can suggest would be some kind of system where part of the token information was sent with the email [maybe a random string] and part stored in the database [a hash of that random string]. So, even if you could read the database, you would need the information sent with the email to effect password reset. Though if you had access to comprehensive mail logs on the box, same problem.

But maybe this isn't as dire as I'm making it out to be...

[Jacob]

Yeah. If an attacker has read access to your settings.py and your users table you've got a lot more to worry about than them changing your users' passwords.