
How do you implement password recovery securely? - benhoyt
Emails are sent clear-text, so how do you implement a password recovery feature that uses email, without resorting to those what-is-your-grandmother's-middle-name security questions?<p>Here's a good way, but it still sends a password via email, so is not good for money-handling sites, and is vulnerable to man-in-the-middle attacks:
<a href="http://blog.moertel.com/articles/2007/02/09/dont-let-password-recovery-keep-you-from-protecting-your-users" rel="nofollow">http://blog.moertel.com/articles/2007/02/09/dont-let-passwor...</a>

======
tmoertel
You're creating a web site and want to lower the entry barrier for people
signing up. So you require nothing more than a valid email address to
register. So far, so good. But now some of your users have forgotten their
login passwords. Now what? How do you reconnect them to their accounts?

One option is to send account-recovery tokens to their email addresses. (That
is the method described in the post that you linked to.) It's a reasonable
method because a valid email address was all it took for your users to
register in the first place. The account-recovery emails amount to asking the
recipients re-perform the original registration test: do they own the email
addresses they claim to own? If the accounts are worth the same now as when
the users signed up (i.e., virtually nothing), that test is probably all you
need.

If, however, users can accumulate real value on your site, even if the value
is small, attackers will have incentive to hijack accounts. So the test for
reclaiming an account must be less susceptible to attack than the do-you-own-
this-email-address test, which is fairly weak.

Unfortunately, that's where your options start to become expensive in terms of
usability. Most users are familiar with entering passwords, receiving emails,
and clicking on links, but beyond that is probably asking too much of casual
web surfers. You can't ask them to sign challenge messages with their private
keys and expect them to know what you're talking about.

Hence the popularity of security questions. Users are familiar with filling
out forms and answering questions, so it's a plausible option for account
recovery. But, as I'm sure you are aware, it has problems. It's not very
secure because the answers to many security questions are limited and
therefore can be guessed. Further, many people are reluctant to provide the
answers in the first place because the "good" questions are invasive. People
are rightfully suspicious when you ask for their mothers' maiden names. So if
your site uses security questions, you raise the barrier for initial
registration, and you'll lose some users right there.

So what other options do you have? If your accounts are somehow tied to the
physical world, say to bank accounts or credit cards, you can piggyback off of
real-world authentication. But that's probably not an option for most Web 2.0
sites.

If none of those options work for you, consider not offering account recovery
at all. When users sign up, make it very clear (several times) that if they
lose their passwords, they are effectively locked out. Tell them to write down
their passwords and store them in a safe location. For certain kinds of sites,
it's a reasonable option.

There are other options, too, each imposing a different set of burdens on your
users and offering different degrees of reliability in exchange. Ultimately,
which is best for you depends on your goals, your users, and your aversion to
risk. There is no one-size-fits all approach for sites requiring more than
trivial security.

(If all you need is trivial security, however, there is a minimal entry level
for all such sites: salt and hash each and every password using a hash
function designed for password hashing, and use recovery tokens for account
recovery. Less-secure options are not any easier, for you or your users, so
there's no justification for them.)

Cheers. --Tom

