[WEB SECURITY] quick question on password reset 'best practices'

[Matthew Chalmers]

Wow, there have been a lot of replies! I'm catching up so apologies if I
restate anything.

The simpler half of the answer is, if the user entered the info (the email
address), there's no reason not to redisplay it, which aids in them figuring
out if they did it wrong but doesn't aid bad guys. There's also no
compelling reason to display any error message in case it is a bad guy,
but...

Others have said "let the [legitimate] user figure it out" but you could be
a bit more helpful by showing what was entered prominently so they can
proofread it, displaying the conditions concisely so they can easily see
they need to proofread in case they mistyped, and/or you could force the
email to be entered twice (disabling copy/paste--yes it can be circumvented
but it's not a security risk here) to attempt to help the user enter it
correctly. Making the page look like a 'warning' instead of a 'confirmation'
that they will ignore without reading will help (colours, formatting, etc.).
If you're designing for accessibility you might have other considerations.

There are other factors to consider as well, but you didn't provide the
details. Maybe the login ID is an email address but that's not the email
address to which a password reset link/whatever will be sent. Maybe the user
forgot his login ID/login email. You should always provide some alternate
way of handling this, like a customer service number, help email, live chat,
etc. The fewer assumptions you make the better. "Threat" modelling might
help (think of assumptions as threats).

There are other ways for bad guys to guess whether they've guessed a legit
email, however, like analysing how long it takes the server to
respond--perhaps entering 10 emails in a row the response is nearly instant
but on the 11th it's much slower in coming--if this either happens at random
or happens only for emails constructed a certain way (like for an intranet
app where everyone's email is similar) the bad guy might guess that when the
email is legit the server does something extra before responding. The best
thing to do is do the same processing for all input so it takes roughly the
same time--do anything extra for a non-discarded request after the reply is
sent.

Yes this is a rather 'trivial' feature of a web site but as you can see
there are many adversarial perspectives, more than we've discussed on this
thread.

Matt

P.S. The last thing you want to do if this is a commercial site is frustrate
your paying customers. But the next to last thing you want to do of course
is help bad guys take advantage of your paying customers. :) There is no
best/right answer, it's all a matter of risk mitigation or cost-benefit,
your preference. You could just not have a password reset feature. That'd
take care of this whole problem, but create another.

On Mon, Jun 2, 2008 at 12:37 PM, Joe White <joe at cyberlocksmith.com> wrote:

> User requests password reset but enters wrong email address as the
> username:
>
> 1)  Username = user email address
> 2)  user forgets password
> 3)  user goes to password reset page in the web app
> 4)  user enters email address as username and requests that his/her
> password be reset
> 5)  user then gets a message similar to the following:
>
> "If the username is valid, you should receive an email with your
> password shortly."
>
> however, what if user enters wrong email address?  is it prudent to
> display something similar to the following message in this case?
>
> "This is not a valid username."
>
> The recon and intelligence gathering implications of the latter
> situation are potentially *huge* but how do you best handle when the
> user enters incorrect username?
>
> any thoughts?
>
> thanks,
> joe
>
> <<<>>>
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20080725/e9dd80bd/attachment.html>