Forgot Password

Hi, i have a quick questions which i hope someone can help me with…

I have developed a site in php / mysql and now i need to add to section where by the users can retrieve their password if they forgot it:

Is it ok to have just one text box “Enter your email address” and then a SUBMIT button which validates the input first and then checks for the email address entered and emails the password to that email address if a record is found… is there anything wrong with this, thanks in advance

Yep plenty. If you email the user their password stored in the database then that means the password is not hashed or encrypted in the database. Therefore, anyone with sql select access to the table can see users’ actual passwords which has obvious security issues. Also, if someone hacks into or steals the database table they will have access to users’ passwords.

Passwords should be hashed or encrypted before storing them in the database table. That way only the user, in theory, knows what the actual password is. If a user forgets their password a more secure way of handling it is this

1 - generate a new random password.

2 - hash the new password and store it in the user’s record in the database ie. replace the old forgotten password.

3 - email the new unhashed password to the user

4 - force them to change their password on their next log in before they can do anything else.

For added security make sure you salt the password. Google salting passwords if you need more info.

thanks for your reply… could i not just hash the password when a user creates their account and then unhash it if they request it using the “forgot my password” form

The only problem with Meldin’s solution is that you are still emailing a plain text password to the user.
Best practice is this.

  1. User requests password reset
  2. Create a unique hash and store it against the user
  3. Email the user a reset password link that includes the hash (ie. reset_password/hash
  4. User enters their email address, the reset hash and their new password in to the form.
  5. Hash the new password and store it in the database, and unset the reset hash in the database

Hashes should only be one way (ie you can encrypt, but not decrypt it).

Ok thanks, but is it not possible to make a site secure without using hash as several big named sites that i use just email you your password if you forgot it… that is why i am curious, thanks in advance…

If that is the case then whether you like it or not, at least 1 person on each site will have access to your actual password. It might be just the head database administrator or it could be several database support people. I certainly would not be happy if a website emailed me my actual forgotten password.

Can you post a link to the home page of some the sites you referred to?

Also, unless I have missed something I see blain’s solution as another way of doing the same function I posted but in a slightly different way. I don’t see how it is more or less secure.

Nowadays clear text passwords should not be stored - too many databases get compromised. The more secure way to do it is:[LIST=1]
[]hash passwords using a one-way hashing algorithm like sha256 with a SALT value (random string normally hashed as md5) combined with the username, password to provide the password hash.
[
]Provide a mechanism on the site if a user forgets their password they have to provide ‘challenge’ information about their account plus the email they signed-up with. If they pass these tests, then a link to create new passwords is given… it is not possible to browse this link without the generated hash passed as a $_GET parameter in the web link in the sent email. These types of links are normally only valid for a short period of time; otherwise the user has to go through the process again.
[*]Once they go to the link they can put in a new password and a new sha256 + SALT +username hash is created for this user and stored in the database.
[/LIST]It is highly recommended that any authentication and password/username login, or changes to the user’s login details or account are only available under an SSL connection. Users should be again challenged for their login username and password (even if logged into the site) to change any of their account info.

Hope this helps,
Steve

Isn’t that what I basically said in post 2? I was arguing against the user being emailed their original clear text password.

Cool, thanks guys… much appreciated…

Yes sorry I missed your post… mine was redundant :frowning:

Another aspect of your original question is: What happens when the user forgets what email they used when they created their account?

Normally I have people register a username and an email address at registration. Then if a user forgets their password a new random password is sent to the registered email address for the user. The user then logs in with their username and new password and is immediately prompted to change their password from the new random one sent to them to something else before they are allowed to do anything else.

Thats another solution but I think Meldin’s solution is perfectly valid, lots of sites and applications do it Meldin’s way. You want to encourage the user to reset the password anyway, once its reset.

The method you suggest can also be compromised, it has the same issue as if you store raw passwords.

Hacker compromises the database
Hacker chooses an account to compromise
Hacker enters their chosen accounts email address into the form
Hacker checks the database for the hash you created
Hacker accesses reset form using the hash
Hacker resets the users password

Some users would see the email and go “oh ****”, but many would discard it.

You could argue that the hacker could change the email address in Meldin’s example and have the email dispatched to their email address, or one they have created, in both approaches, but thats somewhat more dangerous and potentially revealing for the attacker.

Anything after this point is moot, they have access to the database.

But they still have to guess column names if they want to change any data in the tables. And none of the solutions are suggesting storing the actual unhashed password anyway :slight_smile:

Tell that to Sony.

edit:
Just getting access to the database is a massive deal, but there is such a thing as damage limitation, hence why we encrypt passwords.

Technically speaking, gaining access to the database could allow someone to reset the password manually, if they know the encryption method, but there are more serious consequences than that.

I’ll say now, if someone got my mother in laws password for any of the sites she uses, they have the password for EVERY site she uses and that probably includes the first half of her online banking.

So, you encrypt the password and use a salt (which is shouldn’t be generated by anything standard, and but based on something more difficult to figure out and is tied to the account, so not any salt value will do).

thanks for the input guys…