If you have forgotten your password you can go through the password recovery chain to have the server send you an email with a link you can click on to set a new password.
While the functionality works, I have two concerns with it:
1. the db password hash is a password equivalent. If your database is compromised even just for reading (for example, through an unsecured backup), the password hash + user id extracted from the database allows an attacker to reset and change the user's password.
2. the "reset password" link in email does not expire until the password is changed. Same underlying problem as the previous item, but a different effect - if an attacker can intercept a "reset password" link in email, they do not need to act on it immediately, they can sit on it as long as they want, so long as the user does not change their password.
Neither of these represents a direct vulnerability, but rather they potentially make a vulnerability in an unrelated system worse. Not a huge hole, but I think it can be improved.
A suggestion: rather than sending the uid+password hash in the email, create a separate "password_recovery" table linked to a user, with an expiration date, and a keyed hash, where the key is not stored in the database (could be in a file or server config). A unique recovery password would be generated and hashed with the server key to be stored in the table, and the recovery password sent in the email; the recovery would look up the [recovery password, server key] hash in the recovery table and verify that it isn't expired before proceeding with the password change/reset operation, after which the row is deleted or invalidated. This would allow the reset link to expire after a configurable time, and to make it only usable once.
This would eliminate the db-dump password recovery potential, and shrink the email-intercept problem to a limited timeframe.
