[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On Jun 3, 2008, at 12: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?


I think it was Robert Auger who recently brought up the question of how to defend against timing attacks on web-based applications and asked how to defend against them. The responses were few and I think indicative of general lack of good ideas on what to do about them. I don't know of any best practices in the webappsec space.

Adding sleep delays might help a little (some had tried the same), but its hard to say how well it'll work. What you're trying to do is smooth out the response times. However, you have to get really exact with the delays, hard to do, and delays with change dynamically with load on the system. I think its possible to detect timing resolution down to 2-digit ms. The other thing that's possible is implement random timing delays in the flow. This would seem to me to be the most viable, but have not tested it personally.

No matter what though, adding timing delays mess with SLA. Delay = Money.


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.


Certainly could be done. This could also solve the timing problem as well provide the email request system is completely separate from the account look up and email sending system. So the timing of their execution wouldn't effect each other.



~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




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

Brought to you by http://www.webappsec.org
Search this site