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

["White, Dain P" <dainw@xxxxxxx>]

This is a great point Jeremiah - I almost always err on the side of
caution and consider any roadblock I can throw in the way of an attacker
a good thing, but in a high volume site I can definitely see a good case
for a less generic response. I wonder if it would be recommended to
Sleep() the login process an arbitrary 10 seconds whether it was valid
or rejected to take away the timing vector?

Additionally, for instances where we already know the email for the
person, why don't we just email the response to them rather than display
it on screen? That way we can be pretty detailed in the issue, provide
contact information and so on, while preserving the information (or lack
thereof, which is also information) against the bad people. 

Something like "We're sorry, there appears to be a problem with the
login information you provided. Additional information about this error
has been emailed to you."

That would also trigger the user that someone's messing with their site,
which is a good thing - the bad side is that it would trigger ALL the
users that someone's messing with their site via a scripted attack -
which of course shouldn't ever happen because we never allow unlimited
login attempts. Or I don't, anyway. 

~Dain

-----Original Message-----
From: Jeremiah Grossman [mailto:jeremiah@xxxxxxxxxxxxxxx] 
Sent: Tuesday, June 03, 2008 9:41 AM
To: WASC Forum
Subject: Re: [WEB SECURITY] quick question on password reset 'best
practices'

Our first reaction is to always limit the amount of information we  
disclose to the bad guys, including valid usernames/emails. However,  
we're not seeing the value of the generic error messages in the login/ 
password reset flows as we might in web-based systems. For context  
I'm talking about timing attacks as described by the guys at  
Sensepost, a highly recommended read:

It's all about timing...
http://www.sensepost.com/blog/1303.html

I've seen similar attacks executed and vulns identified as they've  
described both before and after their papers release on a number of  
websites. For the most part an attacker can tell which usernames are  
valid on the website whether or not you get a generic error message  
by the speed of the response.

IMHO, the larger the userbase and more predictable the usernames, the  
less valuable generic message are. Big systems make bigger targets of  
username/email address harvesting. So on smaller systems, generic  
messages are advisable. On bigger ones, the value is likely  
diminished and would cost more in customer support if/when implemented.

Regards,

Jeremiah-


On Jun 2, 2008, at 10:37 AM, Joe White 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
>
>


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


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