Forgot password page, but passwords are hashed

Question

I need to implement a Forgot Password page, but my passwords are salted & hashed. So I can't retrieve them conventionally. My idea was to do the following:

• When an user clicks the Forgot Password link, they naturally need to type in their email address (which is also their username).

• Their password gets reset to a hashed & salted password i made. Then, i send an email to them which contains a link to a new page where they can type in their new password.

• The link contains the new hashed & salted password (as a $_GET variable) which is just for authentication purposes.

• I just grab the $_GET variable from the link, authenticate against entry in DB and hash & salt new password and insert into db.

How safe is this? For a site that won't easily be targeted by spammers and brute force attackers.

Thanks in advance.

Answer 1

Yahoo says users should change their passwords and security questions and answers for any other accounts on which they used the same or similar information used for their Yahoo account.

The organization is approaching clients to audit their records for suspicious movement, and to consider utilizing Yahoo Account Key, a basic confirmation device that wipes out the need to utilize a secret key on Yahoo inside and out. I really hope that their security points will help users to restore their account with the link -https://gallery.technet.microsoft.com/Simple-Tips-to-Secure-your-b53badda

Answer 2

You are externalizing the security of your user's account to the security of the email account, so if their Yahoo/Hotmail/Gmail password is 'password', while you enforce strong password restrictions, so someone could get into your site by hacking the user's email account.

That being said, your basic setup is good - I wouldn't worry about spammers hammering on the form - as long as you don't allow user-provided text into the form, then there'd be no point in spamming it - the penis pills for russian brides in time shares special offers won't get through. if a stupid bot does start hammering on the form, you can always put in a limiter so that no more than 1 outstanding password reset email can go out every X minutes.

Answer 3

This sounds fine; for total security on a more frequented site however, a slightly different method would be worth considering:

• Have the user type in their E-Mail address as usual

• Populate a second password field with the random password you build and send out

• Populate an additional column with the date and time the second password was generated

• If the user doesn't react (i.e. log in with the new password) within 24 hours, remove the password from the second column

In the E-Mail with the new password, explain to the user that if they didn't request the new password, they can just ignore it.

This way, a third party entering a user's E-Mail address can't block a user from their own account by resetting the password completely.

Answer 4

As long as you use a good hashing algorithm (md5 is broken and should not be used for cryptographic purposes). Use sha1, and this sounds about like the industry standard. I typically salt and has a random password and just send them to a link with them as get variables, no need for the user to know a new password or copy/paste it.

Also, i don't reset the password to generate this key, i set it as a 1 time authorization code so that if it was not the user who requested the reset, they don't have to find it in their email or request a reset themselves.

Answer 5

Usually you just want to send them the raw but randomly-generated new password. They get to the reset page, and they get to enter a new password.

Them having to view it in their email would make sure that they own the account (after checking that you do have a user with that email).

Then your reset code in $_GET can contain another random string (not the password), get the user to type the generated password you send and the new password (with confirmation).