[WEB SECURITY] Password Reset

Jim Manico jim at manico.net
Wed May 26 12:53:58 EDT 2010


 > 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



More information about the websecurity mailing list