What do you guys think is a better and safer way to handle forgot password? Many sites out there reset and create a temporary password and send it in email in plain text.
Others normally ask you to provide email and send a link via which you can reset password. It probably is easier to reset password and send it for one time use in an email as long as it is hashed and stored.<p>What do you guys recommend?
You need to worry about users who have other people maliciously requesting resets just to bother them. A password reset link in email is the more easily ignored. If you send a new password, you need to make sure you still accept the old one in case it wasn't them who requested the reset. You'd also want/need to time out the 2nd "reset" password after a short period, as you don't want someone who gains access to their email account to be able to use it sometime in the future (possibly long after they've lost access to the email account). Long story short - use the reset link, there are good reasons why it's the widely used choice.
I give people a magic log me in code, good for 24 hours. (I lie - it is actually good for 48, to minimize user error.) For convenience there is also a URL, and the code works in the password box on the login form (until expiry).<p>Anyone using this to log in gets a prominent reset Your Password option after login.<p>This is, relatedly, how I log into people's accounts for support purposes, since I can generate your magic code for today at will.
Please send out the URL; my Facebook account would be unusable if I got a new password every time somebody decided to mess with me.<p>1: <a href="http://dl.dropbox.com/u/9802610/Screenshots/06.png" rel="nofollow">http://dl.dropbox.com/u/9802610/Screenshots/06.png</a>
As a site user, I'd want to just have a link I can click to pick a new password.<p>I'm not going to use/keep the generated password you send me, so just linking me to a page that lets me pick a new password to begin with works best for me.
If you just send a new password, the user may not change it. (They may count on the browser to remember it, or figure they'll just refer to the email again in the future.)<p>As a result, any future brief read-only compromise of their mailbox revealing that password may grant unauthorized access to their account.<p>Sending a time-limited link forces the choice of a new password. They might choose unwisely, but it would take an active compromise of their mailbox (intercepting a future reset-request) to leverage a password-reset to future compromise. If they do choose a bad password, that could be as bad as having your password sitting in their mailbox.
Send an expiring URL to a "choose a new password" form. Resetting the person's password allows for a denial of service where an attacker can constantly reset a person's password out from under them. When you email a URL to change the password, the old password is left alone until the link is clicked and a new password entered.
1) I like the single-use token, but I'm interested in hearing others' perspectives.<p>2) Don't just hash. Use bcrypt, since it's probably got a library for you to use in your language (or database) of choice: <a href="http://codahale.com/how-to-safely-store-a-password/" rel="nofollow">http://codahale.com/how-to-safely-store-a-password/</a>
I've got a slightly tangential question on this topic if you will. Do you track any stats on how many people have trouble with either finding or using the "forgot password" process? I'm asking because our web app follows standard forgot password process (the "send me a hashed link to the reset password page via email" version) but 25% of calls to our helpdesk (>1000 per month) are requests for help to reset their password. We've tweaked the process numerous times to try and make it more visible/easier, but the numbers remain pretty much the same. I'm curious as to whether anybody else is seeing similar numbers?
I use BCrypt, and do the following:<p>1. replace their current hash with "<i></i><i>LOCKED</i><i></i>", plus some random noise.<p>2. generate a random string, and store the hash in a "forcedResetToken" field for the user.<p>3. email them a URL, part of which is the token.<p>4. when the link is activated, I look up the user account by
the hash of the token, force them to choose a new pw, and remove the forcedResetToken.<p>That's the approach I take in my Wicket Quickstarter project (<a href="http://armhold.com/store" rel="nofollow">http://armhold.com/store</a>).<p>Based on other comments I'm seeing, I'm now planning to also add an expiration of the token (say 24 hours or something).
I've always been partial to something like <a href="http://spacebug.com/tableless_secure_one_time_password/" rel="nofollow">http://spacebug.com/tableless_secure_one_time_password/</a>.
I assign them a token that is associated with their account.<p>The token is included in the link sent to them (via email) that directs them to where they can reset their password.<p>The token is only valid for 24 hours and is unique so it can be authenticated against their email when they're resetting their password.<p>If someone logs into that account in the meantime, the token is removed and the link to resetting their password becomes invalid.
The work it would take to make the specific generated password "one use" would be more effort than to send a reset password link. That shouldn't take any effort at all, really using any sort of tool/framework. One guy implemented it in like a half hour for our MVC3 app.<p>I get irritated like none other with stuff like that. It's just like emailing me my password in plaintext. If the user doesn't change the password, that email becomes a potential vulnerability. If a hacker gets access to that email, if they leave themselves logged in somewhere public, etc, etc. That password just became free game.<p>Plus, I have to copy/paste the password (what about mobile users, that's annoying), then I have to go reset the password myself which means digging through your site... THEN I have to again go retrieve the password to change it.<p>Plus you have the users that won't reset the password themselves manually... If you actually make it one time use only... then it's effectively the <i>Exact same thing</i> as just sending a reset link...<p>PLUS I can request a password reset for a random users account... locking them out until they check their email. That's horrendous, I can DOS your users trivially.