Dealing with encrypted password resets

[TechBoyJK]

Hi Guys,

I'm working on a site and I am hashing all user passwords. This way, we don't have an actual copy of their password.

Because of this, if someone forgets their password, we can't just email it to them, because we don't actually know it. So instead, we will reset their password to something random, and email it to them.

As it stands right now, if you go to login, but forget your password, you can first ask for a password hint, which is something you input when you register. If you still can't remember it, you can then ask for the password to be reset and emailed to you.

This is all fine and dandy, but I'm worried about that being abused.

I'm going to integrate a captcha for password resets(that way someone couldn't run a script that would go and reset a bunch of usernames).

What are some other ways to deter people from just entering in other people's usernames and resetting their password?

Should I not automatically reset their password? I was thinking of maybe just emailing them a link, which when clicked, THEN resets their password, and displays it on screen so they use it to login, then change their password to something they remember.

Is that the best way? I'm thinking it might be better since it avoids sending a password in clear text via email, and if someone starts putting in other people's user names it won't matter because you have to actually get the email to the email on file to click the link and reset it.

 

[Shilohen]

Emailing an unique link is, I believe, the most common way to handle it. I cannot think of a better one either, so I'd say go on with it. However, I think users should be offered to enter a new password instead of generating a new one, else you're most likely condemning them to go manually change it as soon as they reset it. Also make sure the reset link is using SSL (https).

 

[TechBoyJK]

hey.. good idea about letting them change it. I didn't like the idea of changing someones password from helokittie123 to SIKJD$%(^*&(*$

So just letting them reset it is probably the best. I'm also thinking about putting an expiration on the link.. maybe 24 hours or something??

 

[Shilohen]

Expiration is definitely a good idea.

 

[BoberFett]

Yeah, a combination of what was suggested here would be my approach. First, generate a random identifier plus an expiration (GUID or somesuch) and associate it with the account; each account could only have a single associated identifier. The link in the email to the reset page would contain both the ID and the identifier, so that both have to match in order to change the password. Then as a last element I'd probably add a counter field which limited the number of attempts at the account/identifier combo so that a random person couldn't request a reset and then attempt to bruteforce the identifier. After X attempts, clear the identifier field and require that a new request be put in which would generate a new identifier. I personally wouldn't even bother with the CAPTCHA at that point.

 

[TechBoyJK]

I'm thinking I'm going to build a table for reset requests.

I want to have a url that is encrypted, so people can't abuse or toy with the script.

something like company.com/resetpw.cfm?key=lkJLDKJFDLJKFLDKJFDLKJFDLFKJD

That key would be a hash of a string comprised of the date of the request, their member id, and a random string.

I would keep the date of the request, member id, and random string in a table.

If the resetlink is clicked and the member ID and random string match, and the date is less than 24 hours from the current date, then it's valid.

ok?

 

[TechBoyJK]

Let me restate.

1. If user wants to reset their password, they will request it by clicking a link, verifying their email and that it matches the email on file for the username they are trying to reset the password for.

2. If successful, user will sent a link. To prepare this link, a unique string (uuid) and the date will be combined into one string, then hashed. The uuid and date will also be entered into a table called "resetRequests", along with the member ID of the request. Lastly, a date will be entered into the table so that an expiration can be enforced.

ex. company.com/resetPW.cfm?key=LKDJFLKDJFLKDJFDLKJ&member_id=324

3. Upon clicking the link, the 'resetRequests' table would be queried for the last request in the table matching the memberID in the link. The UUID and date from the table would be hashed, and that hash would be compared to the 'key' value in the string. If they match, then it is a valid, secure request.

4. Lastly, the value of now() would be compared to the datetime in the result set, and if the time diff is less than 24 hours, the request will be granted.

5. From here, the user will be presented with a small form where they can enter in a new password and password hint.

 

[Cogman]

How tight is this company? Is it going to be just an inhouse product or is it going to span multiple companies.

If it is just in house, I would give IT guys the ability to change passwords, and let the user call/email the IT guy if they forget their password. This makes it impossible for some script to crawl in and screw things up.

Otherwise, what you are doing is probably best. I would still give admins the ability to change passwords though, just in case.

 

[TechBoyJK]

How tight is this company? Is it going to be just an inhouse product or is it going to span multiple companies.

If it is just in house, I would give IT guys the ability to change passwords, and let the user call/email the IT guy if they forget their password. This makes it impossible for some script to crawl in and screw things up.

Otherwise, what you are doing is probably best. I would still give admins the ability to change passwords though, just in case.

This is going to be for a website.. Not an intranet or anything. So it would be more for controlling users, like on facebook, than company employees. I surely don't want thousands of people calling for password resets.

 

[Cogman]

This is going to be for a website.. Not an intranet or anything. So it would be more for controlling users, like on facebook, than company employees. I surely don't want thousands of people calling for password resets.

🙂 then what you are doing is probably best. Especially if you expect it to be big.