Fog Creek Software
Discussion Board




Password attacks by brute force

I have a pretty simple site hosted by my college - the site made up of servlets and is hooked up to an Oracle database. The site serves up software to authorized users.

Lately there has been attempts to crack the site - the login name, due to legacy reasons, are pretty easy to guess. For example John Doe's loging name is 'jdoe'.

Some one, as a hoppy, keeps hacking the site and trying to crack the password of a select set of users.

The site is pretty simple - i.e. we do not have much logging etc and user stats are kept by Tomcat and Apache logs. ( Apache is used as an SSL bridge to Tomcat)

Is there a good way to prevent guessing of passwords by brute force for a web application? When I attempt to SSH login to a Unix machine I have three shots and then it prevents it.

What would be a good way to add this security percaution to a web application?

Should I capture the login name in the Tomcat log and each time a user attempts to login - check from the Tomcat logs if there are more than three attempts to login in the last, say, 5 minutes.

Or should I keep the login counts in a database table and read the login attempts from there? These seems like an expensive way - with lots of additional database connections.

Any tips?

I check by attempting to login to my internet bank - there were no attempts to control the number of login attempts.

Running Mate
Wednesday, July 07, 2004

One possibly it to try and delay the attackers.  Whenever the passsword is incorrect -- wait a while before returning a result.  This cuts down on the number of attempts a hacker can perform.

Or perhaps a better response is to allow 3 failed attempts for a particular user.  After 3 attempts, disable that users account.  There are a couple of ways this can play out:

1) If you have the email addresses of all the users, after 3 failed attempts, send them an email with a link to reactivate there account.  If the user has lost their password (hence the 3 failed attempts) give them an option to change their password.  It becomes a feature!

2) Disable the users account for a period of time, say 3-4 hours or even 24 hours.  A hacker might end up disabling your entire userbase but they'll also probably give up trying pretty quick.

Enjoy!

Almost Anonymous
Wednesday, July 07, 2004

Why fuck around with logging or databases?  Just track login attempts in memory using application state.  Date stamp each user's last three failed login attempts.  If all three occured within X amount of time, don't allow any more login attempts until Y.  There is absolutely no need to persist this stuff to a database unless your webserver is crashing every 3 minutes.

Mr Fancypants
Wednesday, July 07, 2004

I would block his IP address from logging in after, say 10 tries. And also contact his ISP and complain.

Matthew Lock
Wednesday, July 07, 2004

I am not sure I would bother running around to ISPs about this.

The suggestions raised to date are all pretty good. You can read some good stuff about password security at:
http://www.owasp.org/documentation/appsecfaq#faq5

OK, a few quick suggestions:

force the use of strong passwords (e.g. uppercase and lowercase, min 6 characters, alphanumeric etc). Many people favour formats like consonant vowel vowel etc to make it a bit easier to remember. it does not deter the password cracking bot, but makes their job much harder.

force the change of password on first log on

force regular change of password

never indicate whether the person logging in has got the username or password wrong

slowing down the refresh rate on the page can help

some sort of lockout after x failed attempts

Patrick FitzGerald
Wednesday, July 07, 2004

> force regular change of password

This probably hampers security as it forces people to start writing down their passwords on paper or post-it notes since they can't remember all the new passwords they have to think of.

Matthew Lock
Wednesday, July 07, 2004

And force the password change like some sites, where you have some set of rules but don't tell the user until they try a password and then you say "invalid password -- must be between 6-8 characters" then they type one with 7 characters and you say "invalid password -- must contain at least one of: %#&(!@ characters in 3rd character" etc.

And put the error messages in small red letters in a screen of clutter, ads, and the previous form.

Sar Khasm
Wednesday, July 07, 2004

Make the delay responding longer and longer. There is a site which claims to track how long your email recipients spent viewing an email and they do that by puting a web bug (1 pixel gif) that they serve 1 byte per second for about 20 minutes. So maybe the response that JoeHacker gets is verrrrrrry slow.

Log the IP address it is coming from and contact your university police/security. The FBI does not like to get involved unless the money involved is over $10k (they want big headlines, not lots of busts).

Look into honeypots, if you have time.

Peter
Wednesday, July 07, 2004

Forcing users to change passwords frequently does perilously little to improve security against a brute force attack (especially given that at most frequent you'll be asking your users to change their password maybe once every two weeks, a guarantee that they'll frequently forget or write it down, and brute force attacks seldom go on for weeks).

Lock out the account for a defined period of time if multiple attempts are made in a short interval (even a 30 minute lockout is highly effective. If the lockout happens after 4 incorrect logins, that reduces the potential brute force attempts to 192 per day, which would take an average of 102 years to crack a fixed 5 character case insensitive alpha-only password. Obviously when a password could be from say 5-10 characters long with case-sensitivity, digits and special characters the time spam for an average brute force increases tremendously). The downside to account lockouts is that it's a "freebie denial-of-service" window -- hit the account of someone you don't like every 30 minutes to lock them out of the system, so IP lockouts are a possible overlay as well (locking out a source IP for a day if it causes 2 consecutive lockouts for instance) with the risk that it could inadvertently block legitimate users (as many big ISPs use mega proxies where thousands of people all seem to come from one IP).

Dennis Forbes
Wednesday, July 07, 2004

There is no DOS attack here. You would only wait a while when the password is not valid. The legitimate user logs in with a valid password and goes through right away.

Frederik Slijkerman
Thursday, July 08, 2004

You could also disable for a period of time by IP address. I guess this could be worked around by more sophisticated hackers, but it could slow them down.

www.MarkTAW.com
Friday, July 09, 2004

*  Recent Topics

*  Fog Creek Home