[WEB SECURITY] Password Reset

Arian J. Evans arian.evans at anachronic.com
Wed May 26 18:24:45 EDT 2010


@DOS - absolutely. But....use-case of the application has a large
impact on likelihood of DOS.

I only see this happen on sites where individuals can benefit from it
-- auction-sites, ticket-purchasing systems, and systems where you are
incentivized to silence/lock-out users. And skiddies trying to take
down the site of someone who dissed them. Otherwise I rarely see
webapp DOS used intentionally.

@Anti-Automation/CAPTCHA

Even CAPTCHAs do not work when the attackers farm out the brute-force
attempts to an army of humans in China. Which they do.

But - as an anti-automation technique - it is a reasonable step.

@Anti-automation "tricks"

Flash Cookies: One down-and-dirty anti-automation technique I've used
in the past is Flash cookies. Profile your user demographic - if high
90-percentile of them support flash, use flash cookies. Set them, and
then check for them.

The current state-of-art in badness automation never supports Flash
(or Silverlight or insert-RIA) today.

There are other advanced techniques you can use to rate-limit
automation that Gunter Ollman and myself have talked about fairly
extensively @Blackhat in 04/05 time frames. Today though I think they
can all be worked around relatively easily by attackers with a little
regex and WGET/POST coding.

In the old days I had luck with activity-threshold & profiling by
using special tokens (cookies, or buried in the path of the URI) that
contained data about the time-rate of the request, number of request,
and modification to any parts of the response.

Today's web-app threat-landscape has changed and I don't think fancy
techniques work as well anymore. (The quality of success is definitely
bound to the type of webapp and use-case, however...)

Today what you will be facing includes global-botnets and armies of
humans in parts of the world where repetitive labor is cheap. Most of
the techniques I used and advocated 2000-2005 time-frame fall down
when faced with those. This has forced me back into a "Keep it Simple
Simon" mode when dealing with webappsec issues like this.

@Master Physical Password - I really liked the idea of printing off a
high-entropy "master account password". My mom does this, and the
problem is that if he puts it in a safe place, she can never find it
again, so basically they go under her keyboard.

@Master Password in The Cloud - I think today in a modern
cloud-computing world it would be faster just to generate those master
passwords and pump them up into Google docs for the users, so they can
fetch them from anywhere later. You could auto-register them for them,
or CSRF their existing account (I'd try to CSRF before
auto-registering them) and slap this into a spreadsheet for them.

Fast, effective, done.

---
Arian Evans



On Tue, May 25, 2010 at 9:19 PM, Gaurav Kumar <gk at pivotalsecurity.com> 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> 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>
>
> Date: Tue, 25 May 2010 15:07:38 -0700
>
> To: 'Webappsec Group'<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



More information about the websecurity mailing list