[WEB SECURITY] Password Reset

Matt Tesauro mtesauro at gmail.com
Wed May 26 14:20:20 EDT 2010


The one thing I've not heard yet on this is escalating time outs for 
failed password attempts.

Under the constraints Jim has lined up, having rigid lock-out is a 
recipe for a call center DOS.

I've only ever seen this once in the wild while testing web apps but I 
can tell you that it sure made trying to fuzz the user/pass pair 
freaking impossible.  I had a known valid username and I left WebScarab 
churning for an entire weekend without success out of curiosity.

Jim:  If you have to work under those constraints, having escalating 
time out for failed login attempts (bonus points for the security 
questions) is a great middle ground between usability and security.

For legit users: They can try the couple of times and get their login 
right with at most a minor slow down.

For attackers: Trying to fuzz/brute force logins is way to painful to be 
practical.  (plus there's likely other vulnerabilities to find)

Cheers!

--
-- Matt Tesauro
OWASP Live CD Project Lead
http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project
http://AppSecLive.org - Community and Download site

On 5/26/10 11:53 AM, Jim Manico wrote:
>  > But I think we've strayed off-topic. I believe Jim was looking for
> some input, not a candid discussion of what we "think", but suggestions
> from us in his approach.
>
> Paul - this conversation is gold. Defensive strategies are not "solved
> issues" and we need more of these conversations on WebAppSec.
>
> This is a simple issue! And yet there are many different (smart)
> perspectives.
>
> I'm getting a lot out of this. Thank you!
>
> - Jim
>
>
>
>
>> nobody said using an "inordinately complicated password".. and
>> honestly, forgetting a password for me occurs constantly and then i
>> remember it about 4 or 5 times in. Especially since I have over 12 of
>> them on different systems - granted, I'm not a "normal" user.
>>
>> bottom line, there isn't such thing as a 100% fool-proof login system.
>> And we'll probably disagree about that. Fact is, this whole topic is
>> arguable to the nth degree. In all my years of experience, a good
>> password policy works.
>>
>> I didn't mean to be or sound "flippant" in the "one-way" comment. But
>> the bottom line is, if one is attempting to defend against
>> brute-force, there are numerous ways to do it without affecting
>> password policy. It all depends on money, time, and value of asset.
>>
>> But I think we've strayed off-topic. I believe Jim was looking for
>> some input, not a candid discussion of what we "think", but
>> suggestions from us in his approach.
>>
>> Paul Summitt, CISSP "Everything should be made as simple as
>> possible, but not simpler."
>> IS/IT Consultant - Albert Einstein
>> 727.698.6289 Cell
>>
>> On 5/26/2010 11:13 AM, Peter Lowe wrote:
>>> I disagree. Forcing people to have an inordinately complicated
>>> password means
>>> that *every time* they log in they're inconvenienced, as opposed to
>>> if they
>>> forget their password. And, honestly, if someone's forgotten their
>>> password,
>>> I think it's unlikely they're going to remember it on that 11th attempt.
>>>
>>> If a hacker is set on breaking in, then chances are they're going to
>>> one way
>>> or another - sure, but at least that "one way" isn't going to be by
>>> brute-force. All the other methods are still valid whether the
>>> account is
>>> locked after 10 failed attempts or not. Brute force relies on being
>>> able to
>>> attempt a password thousands of times a second, which is fairly easy to
>>> protected against without massively inconveniencing the user, or
>>> forcing them
>>> to use some ridiculous password scheme.
>>>
>>> Paul D. Summitt wrote, On 26/05/2010 15:49:
>>>> I have to agree with Gaurav, locking out accounts because of multiple
>>>> attempts at login (especialy 3 or 5 - ooohhhh I hate those systems)
>>>> only
>>>> punishes the user who has legitimately, and most likely, temporarily
>>>> forgot their password. 95 times out of 100 the lockout usually occurs
>>>> on the legitimate user and not the attempted break-in. If a solid
>>>> password policy is in place (and adhered too), you've defeated 3 out of
>>>> the remaining 2 hackers and kept your user base happy. The remaining 2?
>>>> If they are that set on breaking in - chances are they're going too one
>>>> way or another. That's what logs are for. If you still don't like this
>>>> answer, then after so many attempts at failed logins, have the system
>>>> send out an email on record to the legitimate user as well as the
>>>> system
>>>> administrator. The user will most likely be calling someone when they
>>>> see this activity and it's not from them.
>>>>
>>>> That being said, I do like systems with security questions or images
>>>> that are used in case you have forgotten your password. But not used
>>>> for
>>>> lockouts. There were a lot of good ideas here - and I simply prefer
>>>> keeping history of users past login locations and if a new one pops up,
>>>> then you have a reason to ask a question. If they are attempting to
>>>> login from a recently known user-used location, then you could think
>>>> twice about lock-outs or at least increase the lock-out count for that
>>>> session.
>>>>
>>>> just some more ideas to think about.
>>>>
>>>> Paul Summitt, CISSP "Everything should be made as simple as
>>>> possible, but not simpler."
>>>> IS/IT Consultant - Albert Einstein
>>>> 727.698.6289 Cell
>>>>
>>>> On 5/26/2010 12:19 AM, Gaurav Kumar wrote:
>>>>> Jim, while others have given many good ideas, I just wanted comment on
>>>>> account lockouts. Account lockout feature is like a DoS vulnerability
>>>>> waiting to get exploited. For example, if an application locks the
>>>>> account after 5 invalid attempts for 10 minutes, what will prevent
>>>>> from
>>>>> someone writing a script which will send 5 incorrect passwords after
>>>>> every 10 minutes? This will essentially lock the account forever
>>>>> thereby
>>>>> creating a DoS on user access. This is the reason you will find
>>>>> applications throwing Human Interaction Proof like captcha images
>>>>> when a
>>>>> brute force attempt is detected.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> *---*
>>>>>
>>>>> *Gaurav Kumar*
>>>>>
>>>>> *From:* Jim Manico [mailto:jim at manico.net]
>>>>> *Sent:* Tuesday, May 25, 2010 5:58 PM
>>>>> *To:* Arian J. Evans
>>>>> *Cc:* Webappsec Group
>>>>> *Subject:* Re: [WEB SECURITY] Password Reset
>>>>>
>>>>> Arian,
>>>>>
>>>>> I only back your proposed solution below if you add Mike Baileys "/Are
>>>>> you who you say you are?/" checkbox. Defense in depth, right?
>>>>>
>>>>> - Jim
>>>>>
>>>>> PS: That was very sarcastic.
>>>>>
>>>>> Also Jim - I should have added earlier - but one of my financial
>>>>>
>>>>> institutions uses pictures for account reset with their questions.
>>>>>
>>>>>
>>>>>
>>>>> Personally I find them cute, and easy to remember. I always go for the
>>>>>
>>>>> pictures of the motorcycles - they catch my eye and super easy for me
>>>>>
>>>>> to remember which one I picked.
>>>>>
>>>>>
>>>>>
>>>>> Maybe a modern solution like this would work for you too?
>>>>>
>>>>>
>>>>>
>>>>> If you can't build it secure - might as well make it fun!
>>>>>
>>>>>
>>>>>
>>>>> Looks like some folks have suggested using public-record data like
>>>>>
>>>>> DOB. That stuff is always fun too!
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Arian Evans
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 25, 2010 at 5:09 PM,<neza0x at gmail.com>
>>>>> <mailto:neza0x at gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Not to much to do with those restrictions. Hopefully, this is not a
>>>>>
>>>>> sensitive system, otherwise I will go for sms cell messages
>>>>> validation.
>>>>>
>>>>>
>>>>>
>>>>> 1. Enforce account locked out for username too.
>>>>>
>>>>> 2. Use captcha
>>>>>
>>>>> 3. Security questions should be tied to PII info instead of simple
>>>>> questions
>>>>>
>>>>> like"color of your first car". You could ask for last for digits
>>>>> of your
>>>>>
>>>>> license, social or employee id. This works for home grown
>>>>> applications and
>>>>>
>>>>> requires other controls like encryption to safely storage of
>>>>> sensitive
>>>>>
>>>>> answers.
>>>>>
>>>>>
>>>>>
>>>>> All depends on the sensitivity of the system you are trying to
>>>>> protect.
>>>>>
>>>>>
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>>
>>>>>
>>>>> Sent via BlackBerry from Danux Network
>>>>>
>>>>>
>>>>>
>>>>> ________________________________
>>>>>
>>>>> From: Jim Manico<jim at manico.net> <mailto:jim at manico.net>
>>>>>
>>>>> Date: Tue, 25 May 2010 15:07:38 -0700
>>>>>
>>>>> To: 'Webappsec Group'<websecurity at webappsec.org>
>>>>> <mailto:websecurity at webappsec.org>
>>>>>
>>>>> Subject: [WEB SECURITY] Password Reset
>>>>>
>>>>> Hey Folks,
>>>>>
>>>>>
>>>>>
>>>>> I have a hard requirement to build a password reset feature that
>>>>> does not
>>>>>
>>>>> include an emailed link or cell phone account verification. I'm
>>>>> thinking:
>>>>>
>>>>>
>>>>>
>>>>> 1) Enter your username
>>>>>
>>>>> 2) Answer a pre-set security question
>>>>>
>>>>> 2a) Ensure the security question answer is at least as strong
>>>>> as the
>>>>>
>>>>> current password policy (ouch - this might radically limit usability)
>>>>>
>>>>> 3) Enforce account lockout around security question failure
>>>>>
>>>>>
>>>>>
>>>>> I still don't like it - which is why I'm spamming you. :) Any
>>>>> thoughts?
>>>>>
>>>>>
>>>>>
>>>>> Aloha,
>>>>>
>>>>> Jim
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>> ----------------------------------------------------------------------------
>>
>> Join us on IRC: irc.freenode.net #webappsec
>>
>> Have a question? Search The Web Security Mailing List Archives:
>> http://www.webappsec.org/lists/websecurity/archive/
>>
>> 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/archive/
>
> 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/archive/

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