In my opinion, you should create $_SESSION['attempt'] and make it
expire every 5 minutes. Everytimes user fail to login, $_SESSION[attempt]
will increase by 1 if user attempt more than 5 times then disable login
page. This is what I think it should be.

Sorry mabye i was a bit unclear - if the user login fails 5 times WITHIN 15 mins, it will block it for 15 minutes.

Intresting concept invisal . any more ?

Everytime user fail to login, set session expire to next 15 minutes. so mean that if they fail more than 5 times it will be block 15 minutes

Maybe it is little unclear. So I give you a real time example:

First I fail to login at : 0:00am so the SESSION will be expire in 0:15am
However, I attempt again but fail at 0:05am so the SESSION will be expire in 0:20am and that $_SESSION['attempt'] probally will be = 2.
I try again at 0:15am and SESSION is not expire yet. This time I fail again. So my session expire will be last until 0:30am

I like the way your thinking Invisal.

I will wait for more replies from other coders, before i decide which is the more suitable method to use.

Thanks for your input

A better way to implement this would be to forget about the user trying the brute force all together, but try and detect a brute force attempt by a pattern in failed login attempts.

You can start simply by saving each failed login attempts to a database.
A simple pattern is 5 failed login attempts on a username. This is without regards to who made the attempts or from where or what IP (these are factors that can be changed by the attacker), just the fact that there exists 5 failed login attempts on a single username in the last 15 minutes.

Of course, you could also try the IP, for those users that don't use a distributed brute force attack, but just use a single IP range. If you have 5 failed login attempts from a single IP, or similar range, no matter what username it is, they it may be a good basis for seeing it as a brute force.

The reason for this is because most brute force attacks would span from different computers that have no common properties as far as your php application can gather. $_SESSION is useless here as it is implemented via HTTP Cookies (or HTTP GET url parameters).

One want to slow down a brute force attack would be to make sure a brute force attempt is not viable. Brute force works on the ability to process multiple attempts on the system very quickly, either from a single computer, or from many. If you place a simple:


it makes brute force less viable, especially for one that has a low probability of finding a username/password match. This is good for attacks which are hard to track like distributed computers sending login attempts on different usernames all at once. They would all have to wait 10 seconds before knowing if the result. For a computer attempting a brute force, thats a century. For the user, it may actually seem more secure - especially if you have a huge sign, "Authenticating...".

If I were to take a guess I'd think Paypal, Ebay etc. use this technique. You have to wait around 1 minute for your login. Now that isn't because it takes that long to authenticate you (maybe it does an thats a plus), and it doesn't matter how fast your connection is, it still takes 1 minute.

To prevent from those attacker that use robot to do multi-attempt, I think
we can use Secure Code Image technique. Robot cannot guess what
code that contain in the image so that robot is useless to attack us.

Yes, a CAPCHA is a great method, I'd like to note a few things that usually aren't considered with CAPTCHAs on login forms, as opposed to on on a non-authenticated form. (such as a public comment form etc.)

A CAPTCHA is ok for preventing spam, but not so much for brute force. You can use it to stop the bulk of attakers, but it does not stop the determined brute force attack.

The CAPTCHA is subject to a few things that a simple thing such as <?php sleep(10); ?> isn't.

1) Can be read by OCR (Optical Character Recognition)
2) Subject to Social based attacks (using people to attack without their knowledge)
3) Subject to Session based attacks

A good number of generated CAPTCHAs can be read by a bot that uses Optical Character Recognition (OCR). At times a bot can be faster than a human at recognizing an optical character.
Even if a bot can only recognize 1% of your generated CAPTCHAs, it has the ability to launch a brute force attack.
The reason CAPTCHAs are used is that they slow down bots. They require a lot of processing power to run numerous OCR software on an image, and only get 1% favorable outcome to exploit on your sever (thus it costs alot).
If the incentive was to post spam on your blog, then a bot would not be interested in wasting so much money on it. If the incentive was to figure out a users password, such as in a brute force, then matching a CAPTCHAs 1% of the time is a doable expense.

Attackers can also use social based attacks on CAPTCHAs. A simple example is generating 1000s of sessions on your server which generate 1000s of CAPTCHA images. The images that cannot be solved by OCR are then placed on login forms, comment forms, forum post forms, etc. on other websites. Users using these websites do not realize they are contributing to a brute force attack. On high traffic websites, the attacker can launch an attack in seconds once they have collected enough validated CAPTCHAs.

Since a CAPTCHA is session based, the single attack can be postponed untill the attacker has 1000s of user or OCR validated CAPTCHAs (before the session times out). Thus the longer they carry out the attack, the faster they can make authentication attempts as they collect more and more user validated CAPTCHAs and store it for the next attempts.

It is not 100% match for using OCR to read the image right? Plus the image is created which randomly content. Even the attacker collect more than 1000 of images that have been appear on the login, the next image will be probally different from the previous. I guess the robots aren't so effective after all now. Correct me if i am wrong...