Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security SecProg
[Top] [All Lists]

Re: Account Lockouts

Subject: Re: Account Lockouts
Date: Thu, 02 Dec 2004 11:16:55 -0500
On Wed, 01 Dec 2004 11:52:13 CST, Harrison Gladden said:

What are successfull techniques that could be used on the web
interface to avoid having a script run against it that would
potentially lock out 15000 user accounts, and create a headache for
the system administrators who have to manually unlock each account?

The four most obvious solutions:

1) If the login attempt rate is exceeded, only lock out the account
for a specified time period (1-4 hours or so?).

2) Set the attempted login limit to (say) 4, and then include code in
the web app to only allow 3 attempts per period.

3) Write some Perl that will trawl the server logs and detect the footprint
of such a script, and automate the unlocking of the victim userids.

4) Make it clear to your users that you *have* a baseball bat and *will* use it 
on
any transgressors.  Think about it - this sort of script is most likely going
to be an inside job.  Your 15K users know about the web app and the lockout
issues - but that script kiddie in Belgium or wherever most probably doesn't.
If the script kiddie knows too, you have *other*, *bigger* security issues.
(Don't give me the "security through obscurity" crap - the point remains that
if people in Belgium know the innards of your business process, you're too
frikking open with your information, and that's symptomatic of bigger problems.
If they know *that*, what *other* info have they walked off with already?)

Attachment: pgp4S1mHLOMn3.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>