Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 33 posts

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

#21

Post by halayli »

kaffeinecoma wrote: post #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 ta…

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

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

#22

Post by edanm »

trotsky wrote: post #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…

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.

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

#23

Post by trotsky »

edanm wrote: post #22
trotsky wrote: post #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…

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.

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

#24

Post by ra »

plasma wrote: post #12
retrofit_brain wrote: post #5

Earlier quoted context omitted.

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 fac…

That's a brilliant idea

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

#25

Post by ra »

halayli wrote: post #21
kaffeinecoma wrote: post #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 ta…

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.

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

#26

Post by dav-id »

drivebyacct2 wrote: post #16
retrofit_brain wrote: post #13

Earlier quoted context omitted.

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.

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

#27

Post by ayers »

gojomo wrote: post #9

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 ta…

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.

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

#28

Post by sievert »

zoowar wrote: post #7

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

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

#29

Post by kiritsinh »

drivebyacct2 wrote: post #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, t…

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.

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

#30

Post by tigger-2 »

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?
Post reply on HN