Re: Account Lockouts
[email protected] Thu, 02 Dec 2004 11:16:55 -0500
| Newsgroups | gmane.comp.security.programming,gmane.comp.security.web-applications |
|---|---|
| Message-ID | <[email protected]> |
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?)
signature.asc
(application/pgp-signature, 226 B)
-----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-----