WebApp Sec mailing list archives

Re: Account Lockouts


From: Valdis.Kletnieks () vt edu
Date: Fri, 03 Dec 2004 14:07:37 -0500

On Fri, 03 Dec 2004 10:02:33 +1100, Michael Silk said:

Not quite sure what you mean here - obviously for each attempt at
login the captcha image supplied would be different ... such that if
they were to attempt to brute force (or just lock-out) 15,000 accounts
that 15,000 images * a subsantial amount.

Well, there *is* some up-front work needed - but the attacker's *liveware*
workload is about the same whether they need just 10 captchas broken, or 15K,
or a million.  The crucial point is that the linear-scaling part (getting
each new "mark" to do the work for you) is both automatable and well understood.

Finding this many users - and finding such an amount to respond in a
timely manner - would surely not be trivial.

Send out some spam with 'FREE PORN' - you'll get 15K takers easy enough. Lots
of spammers are getting rich running a spam and collecting the victims in the
12-36 hours before their access gets yanked on *that* account or domain, and
then move to the next.  "Timely manner" is a well-understood problem.

And it's not a problem to do it "timely" - For each captcha you want solved,
you wait till one of your Joe Sixpacks clicks on the link for free porn on
your website (which can easily be on some zombied box on a cablemodem somewhere),
and when he connects, you then call the target site and get the captcha, hand it
to Joe Sixpack, wait for his response, and send it to the target site.

Oh, and you don't even need any actual porn - just dump the dupe after he's
done your work for you.. ;)

Sure .. but how would you solve this issue, then, if you were truly
concerned about someone targetting your site specifically to lock out
all the accounts ?

Think Outside The Box.

An attack designed to lock out all the accounts is only a problem if you've
designed your system such that accounts can be locked out, and that it causes
an actual problem when they're locked out.  If you don't lock them out, or
it doesn't cause a major problem when you do lock them out, the attack can't
evolve from "aggrivating" into "crippling".

Possible countermeasures:

1) Don't lock accounts out.  (Think about it - why are you locking accounts
at all?  What does this do that simply time-limiting the account to one logon
attempt per minute doesn't do?)

2) Design your web application to know what the lockout limits are, and
refuse requests that would result in a lockout.  If it takes 5 attempts
per 10 minutes to lockout, and the web application refuses to issue more than
3 every 10 minutes, you don't have a lockout problem.

3) Lock accounts, but only for an hour or so.  This is still annoying, but
at least then you don't have to have the sysadmin resetting 15K accounts...

Attachment: _bin
Description:


Current thread: