Ask HN: Strategy for password reset email vs URL to reset pwd | Hacker News Reader

Ask HN: Strategy for password reset email vs URL to reset pwd

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.

What do you guys recommend?

View on HN

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.

How common is the resetting someone's password to annoy them? I know it's a very common rationale for sending reset links, but I'm trying to remember if I've ever heard of it actually happening for real, and drawing a blank.

I'm sure it's service dependent, with some services the frequency would likely be essentially 0, but some services like popular online games you'd see it happen widely the first day you allowed it.

The problem is, one person does this you pretty much have to change your code immediately if you disable an old password. And while I focused on the malicious, don't discount the accidental - my gmail routinely gets sent email meant for people who couldn't enter their own email address correctly when signing up for various things. If out of the blue a customer can't use their password and has to go find a new one to enter they aren't going to be too impressed even if it doesn't happen again.

i get about one bogus password reset request every two months for my gmail account...

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).

Anyone using this to log in gets a prominent reset Your Password option after login.

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.

1: http://dl.dropbox.com/u/9802610/Screenshots/06.png

As a site user, I'd want to just have a link I can click to pick a new password.

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.

Hmm...interesting. Click wise it probably is less clicks and you are also forcing the user to change his password. Unless you add logic to ask the user to change his password with one time token, it probably makes more sense to send a link to reset pwd.

You may want to look into using HMAC Urls (with a timed expiration date), see http://en.wikipedia.org/wiki/HMAC for a quick explanation.

This lets you send a link like www.mysite.com/resetpassword?userid=123&timestamp=...&hmac=.... without having to keep a database backed copy of 'reset password' emails and tracking sent links.

You can make it so the link only works for say a few hours or any other combination of factors, the HMAC lets you 'sign' the URL you issue the user so it cannot be changed/forged, and you append a 'timestamp' argument to then let you determine if you consider the URL too old to take action on.

That's a brilliant idea

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.)

As a result, any future brief read-only compromise of their mailbox revealing that password may grant unauthorized access to their account.

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.

I can second that people will rely on the browser to remember the new password or copy/paste the password and then refer to that email when they need it again. I do this myself sometimes for some sites that I do not use regularly. Like many others have suggested I think a link to a form to create a new password would be better than emailing out a temporary new password.

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.

Never email a plain text password, it sends the wrong message about your commitment to security.

Yes I see this so many times, even on big sites with millions of users. It's great for usability though, as I can go "ahh, that's what it was". As for security, most people's passwords are vulnerable to dictionary attacks anyway

1) I like the single-use token, but I'm interested in hearing others' perspectives.

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: http://codahale.com/how-to-safely-store-a-password/

We do use BCrypt. Trying to figure out if implementing an extra layer of sending an email with a link to reset password has advantages over just sending a one time changed password.

It is easier on the user.

Why don't you just send a link that includes your one time password? This will allow the user to choose a new one just clicking on the link and setting the new password, instead of going to your page, logging in and changing the password after that.

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:

1. replace their current hash with "LOCKED", plus some random noise.

2. generate a random string, and store the hash in a "forcedResetToken" field for the user.

3. email them a URL, part of which is the token.

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.

That's the approach I take in my Wicket Quickstarter project (http://armhold.com/store).

Based on other comments I'm seeing, I'm now planning to also add an expiration of the token (say 24 hours or something).

So if I know a user's email I can lock their account by just triggering a reset password.

Yeah brute force lockout is a destructive attack.

A better lock-out approach is to disable logins for a period of time (say 1 minute)... i.e. as someone said above, you don't want to destroy the old password in case the reset was requested by someone else.

I've always been partial to something like http://spacebug.com/tableless_secure_one_time_password/.

I assign them a token that is associated with their account.

The token is included in the link sent to them (via email) that directs them to where they can reset their password.

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.

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.

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.

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.

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 Exact same thing as just sending a reset link...

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.

This makes more sense, random users being able to request RESETS. I agree sending a time bound link to registered email is better.

What type of token generation mechanism would you use to send with the link to identify a user or to make sure that the link is being requested by the right user.

I can't think of anything in particular you'd need to worry about. Something long enough that it would be infeasible to try and attack. We just use GUIDs, but those may be predictable if you know the generation time (I'm not sure about that, to be honest).

I do exactly the same thing.

The guid is set to expire after a period of time and requires that registered email and the key together. It won't allow login, only changing of their password.

I agree on the fact that 'Generate temp password' will require more dev and user efforts but i don't think 'generate password' is more vulnerable than the link if the generated password is time bound. Also to make 'the link' more secure we need to verify the user identity. To make that happen need to store the user identity in the application.

>i don't think 'generate password' is more vulnerable

No offense, but I listed reasons why it is more vulnerable.

>Also to make 'the link' more secure we need to verify the user identity.

What? No. That's completely wrong. You're inherently trusting the user's email address. Maybe make them answer a security question before sending the link, but otherwise, there's nothing else to secure.

If the user can't login, how do you plan to verify the user identity? And I have no idea what "need to store the user identity in the application" is supposed to mean...

Reply on news.ycombinator.com