Brute force password attack prevention

For quite some time, I have been playing around with the ideas of being able to secure Phosphorus Five from brute force password attack, and actually once you spend time on it (pun!), it is actually quite simple. My idea came from being a regular user at, where you have a “cool down period” between each comment you’re allowed to submit. This is something I assume Reddit implemented to prevent a single user to flood a thread with dozens of comments, which is actually kind of cool, though slightly annoying every now an then I must admit. Basically, if you try to post more than x comments during some fixed time period, it will deny you to post your next comment, and inform you that you’ll have to wait some x minutes before you’re allowed to post another comment.

A brute password dictionary attack, will mostly be implemented through a “dictionary attack”, based upon some “x number of common passwords”. Now assuming you have an averagely complex password, or combination of common words and character combinations, and some adversary can try 5 password per second – A brute force attack your server by guessing your password, seldom takes more than 1 day or two – If that much!

Time is your friend

By implementing a similar “cool down period” as Reddit did for their commenting system, on the same username, we can significantly increase the required time needed to brute force attack a server. If we set the cool down to say for instance 60 seconds between each successive attempt – Then all of a sudden you have increased the time necessary to open your server from 1-2 days to 300-600 days. If you create good password routines, which implies changing your password twice a year (at least), this implies that long before any brute force attack has been successfully implemented, you’ll have invalidated the entire process, by having changed your password.

Now the implementation has a couple of “buts”, which among other things is that it must be implemented on a “per username basis”. If you implemented it on a “per IP basis” for instance, you would not guard against a *distributed* brute force attack, which could simply utilise a bot net with 300 different servers, and 300 different IP addresses – Which would completely invalidate these security measures, eliminating this “cool down period”. Hence, it must be implemented on a “per username basis” to be effective.

This has a couple of side effects, which among other things implies that if your server is under attack from a brute force attack, then you won’t be able to login to your own system yourself. This negative side effect, can be significantly reduced though, to the point of almost oblivion – By simply still allowing users to login through their persistent authentication cookies. Since these cookies (should be!!) implemented as some sort of hashed string, there would be little if any point in implementing the same brute force protection for people accessing the system through their existing credential cookies. Trying to brute force a hashed string, is basically useless, since the number of permutations are simply too large. And as long as you salt your passwords, then creating a pre salted rainbow database over a password dictionary, trying different hashed values from your password dictionary, becomes literally impossible – Assuming you keep your salt a secret.

All in all, I must confess that I am pretty confident in that this is a pretty nifty idea, which significantly reduces an adversary’s ability to crack a server. And obviously, this will be an integral part of the next Phosphorus Five release 😉

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s