Calle D. wrote:
A workaround would be to generate a new password and send it to the
user. If the user then want to, he may change to another password.
This is the right way of doing it. To up the security another notch,
force the user to change their password the first time they log in
with the mailed-out one (mail is not a secure distribution path).
I’d avoid changing the password at all until you have some assurance
that the reset request is legitimate. Consider the scenario where
someone comes along, tries to log in as you, clicks “I forgot my
password”. Now your password is changed and you can’t log in until you
go dig into your email to discover that you need to use something
different. Let’s hope that email isn’t lost to an overzealous spam
I’ve solved this problem in the past by using a separate column in my
users table where I generate some unguessable token, then email a link
to the user at their email address of record. The link contains the
token, and if it matches what I have in the DB, I let them change their
Also remember that storing a simple hash of the password is less than
ideal, too. An attacker that gets your database only has to generate
hashes for his large dictionary of passwords, then compare this to your
DB. Adding salts (a few characters of randomness) and then MD5’ing
salt+password defeats this attack.