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

Jeremiah Grossman jeremiah at whitehatsec.com
Wed Jun 4 11:47:00 EDT 2008


Hmph, that's a really interesting observation. Depending on who the  
attacker is they don't necessarily have to start from scratch. I  
could see the technique being useful in smaller website niches with  
smaller user-bases.

Regards,

Jeremiah-

On Jun 4, 2008, at 1:29 AM, Stephen de Vries wrote:

>
> Using email addresses bear special mention in this case because  
> simply knowing that a certain email address is registered to a  
> particular site could be valuable information in itself (and not  
> just useful for the purposes of brute forcing the password).  Some  
> examples that spring to mind:
> - Competitor A would like to know which of it's users also shop at  
> Competitor B so that it can better target it's marketing efforts.   
> If competitor B allowed email enumeration as described, and  
> competitor A already had a list of its existing clients' email  
> addresses to check... boom.
> - Spouses could check whether their partners are registered to  
> gambling/porn/dating sites.
>
>
> Stephen
>
> On Jun 3, 2008, at 9:17 PM, White, Dain P wrote:
>
>> 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 at whitehatsec.com]
>> 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
>>
>
>
> ---------------------------------------------------------------------- 
> ------
> 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



More information about the websecurity mailing list