[WEB SECURITY] Password Reset

Paul D. Summitt pauld at summitt.net
Wed May 26 10:49:20 EDT 2010


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5136 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20100526/146dc535/attachment.p7s>


More information about the websecurity mailing list