Valdis.Kletnieksvt.edu
Date: Thu Dec 02 2004 - 10:16:55 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFBrz/2cC3lWbTT17ARAokfAJ9wbrgUtcqUq+0opXL1iCuSD1Tf9QCg6SQT
M4Ejwp0bN4wkV04e0uDSb9M=
=uoJw
-----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]