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

Re:Ask HN: Strategy for password reset email vs URL to reset... by drivebyacct2 on Sunday July 17, 2011 @09:43PM (#2774797)

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.

[ Parent | on HN ]

Re:Ask HN: Strategy for password reset email vs URL to reset... by kiritsinh on Monday July 18, 2011 @08:01AM (#2775924)

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.

[ Parent | on HN ]

Re:Ask HN: Strategy for password reset email vs URL to reset... by drivebyacct2 on Tuesday July 19, 2011 @03:59PM (#2782791)

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

[ Parent | on HN ]

Re:Ask HN: Strategy for password reset email vs URL to reset... by retrofit_brain on Sunday July 17, 2011 @09:51PM (#2774812)

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.

[ Parent | on HN ]

Re:Ask HN: Strategy for password reset email vs URL to reset... by drivebyacct2 on Sunday July 17, 2011 @10:25PM (#2774881)

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

[ Parent | on HN ]

Re:Ask HN: Strategy for password reset email vs URL to reset... by dav-id on Monday July 18, 2011 @03:25AM (#2775426)

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.

[ Parent | on HN ]