Live data from Hacker News

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

news.ycombinator.com

11–20 of 33 posts

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

#11
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.

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

#12
post #4

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.

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

#13

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, t…

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.

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

#15
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.

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

#16

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, t…

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

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

#17
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.

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

#18

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.

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

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

Post reply on HN