Web Hosting Talk : Web Hosting Main Forums : Programming Discussion : Simple Forgotten password reset script

[Shib]

Hey,

So I am working on my own script right now that I am using for my hobby website. I have a MySQL database set up with the user's information (name, password, email etc...) and I am working on creating a password reset function. I plan on making a page where the user can go to the page, enter their email and username and it will then reset there password. I have thought of one way of doing this.

1. User inputs there username and email, when they submit the form a unique hash is created (probably SHA1 with a randomly generated salt + there userid or something to make it unique) then stored in the database.
2. The user is emailed this unique hash code and then must enter the code into an input area (or click the link emailed to them), if it is a match then let the user continue to the next step or if it is wrong then allow the user 3 more chances to reset there password before they are blocked (by IP)
3. Allow the user to change their password.

Do you guys see any problems with this way of resetting passwords?

Thanks,
Shib

[quantumphysics]

Don't forget to fuzz up username/email input, have a message like "if it exists you'll get a message soon" so random people can't match email addresses with people brute-force

Make sure the reset hash expires very fast.

[TwineDev]

You may also want to consider a separate table to track the hashes. I have seen people go, request password change. Don't see it in the e-mail right away, go back and try again, so it actually generates a new hash. But then the first e-mail comes in with the first hash. If you are only storing the latest request, that first one is gone.

Some other extras: Save the time stamp of when the hash was created, so it will only work for a certain period of time (say 24 hours).

In the e-mail, give only bare minimum information, but I like to aslo list what IP made the request and reassure people that if they were not the one to make the request that they do not have to do anything and their login will remain the same

I had one client request adding a link to "force kill" the hash, so if the users e-mail was compromised, they could prevent others from using the link. (that site allows people to enter a secondary e-mail for contact)

If you are allowing people to login via a username separate from their e-mail address, track on in the hash database if they requested the password via username or email, and if by username, when they come back into the site to finish the changing, require them to give the username again (helps prevent in case of compromised e-mails)

[Shib]

Originally Posted by quantumphysics

Don't forget to fuzz up username/email input, have a message like "if it exists you'll get a message soon" so random people can't match email addresses with people brute-force

Make sure the reset hash expires very fast.

I have implemented something similar to what you suggested. When the user supplies a username and e-mail address, if there is a match in the database then a randomly generated hash code is created and e-mailed to the users listed e-mail account. This has code expires after 10 minutes, however I am thinking on bumping this up to a few hours to make sure that it will be delivered in time and still be active (in case of spam filters and such slowing it down).

Originally Posted by TwineDev

You may also want to consider a separate table to track the hashes. I have seen people go, request password change. Don't see it in the e-mail right away, go back and try again, so it actually generates a new hash. But then the first e-mail comes in with the first hash. If you are only storing the latest request, that first one is gone.

Some other extras: Save the time stamp of when the hash was created, so it will only work for a certain period of time (say 24 hours).

In the e-mail, give only bare minimum information, but I like to aslo list what IP made the request and reassure people that if they were not the one to make the request that they do not have to do anything and their login will remain the same

I had one client request adding a link to "force kill" the hash, so if the users e-mail was compromised, they could prevent others from using the link. (that site allows people to enter a secondary e-mail for contact)

If you are allowing people to login via a username separate from their e-mail address, track on in the hash database if they requested the password via username or email, and if by username, when they come back into the site to finish the changing, require them to give the username again (helps prevent in case of compromised e-mails)

I have also taken your advice and I have implemented a new table that stores the requested user ID, hash code and then the time it was created. When the user clicks the link in the e-mail they are sent it will query the database to see if there is a matching has code and requested user. If the time is less that 10 minutes (or like I said, I might change it to a few hours) it will e-mail the user a new randomly generated password so they can log in.

Also, if the user has submitted a request for a password reset and then another request is made for the same user, it will not send another email or generate a new code(it checks the request table to make sure there are no duplicate user IDs). So pretty much in the case of multiple attempts, the user must wait for the code to expire before they can create another, perhaps I should implement some kind of “force kill”

I am also probably going to add some kind of IP address logging like you suggested.

Thanks for the helps guys!