
Ask HN: Strategy for password reset email vs URL to reset pwd - retrofit_brain
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?
======
trotsky
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.

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

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

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

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

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

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

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

~~~
ra
That's a brilliant idea

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

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

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

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

~~~
sievert
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

------
carbocation
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/>

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

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

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

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

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

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

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

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

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

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

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

