A better strategy for blocking any brute force attack is to incrementally delay the page response after failed login attempts. After the first failed login attempt, for example, the response would be delayed by one second. After the second failed attempt, the response would be delayed by two seconds, and so on. A one-, two-, or even six-second delay is probably not going to bother a human userdh too seriously. Certainly he will find it less irritating than having to wait 30 minutes for his account to reactivate because he accidentally left his caps lock key on. On the other hand, an incrementing delay can completely defeat an automated tool being used for a brute force attack. Assuming the tool could normally make ten requests per second, the time it would take to make one thousand requests would jump from two minutes to five days. This pretty much renders the brute force attack tool useless. An incrementing delay also solves the problem of the attacker holding the password constant and varying the username. Since the system tracks failed login attempts on a user session basis and not an authentication credential basis, the delay logic cannot be bypassed this way.
@Shlomy - just to be clear, the text in my comment was cut-n-pasted from the link. The other paragraphs on the page are what the author was referring to by a better strategy.
But in answer to your question, yes something exactly like you posted.
From: http://www.wwwcoder.com/Default.aspx?tabid=68&...
A better strategy for blocking any brute force attack is to incrementally delay the page response after failed login attempts. After the first failed login attempt, for example, the response would be delayed by one second. After the second failed attempt, the response would be delayed by two seconds, and so on. A one-, two-, or even six-second delay is probably not going to bother a human userdh too seriously. Certainly he will find it less irritating than having to wait 30 minutes for his account to reactivate because he accidentally left his caps lock key on. On the other hand, an incrementing delay can completely defeat an automated tool being used for a brute force attack. Assuming the tool could normally make ten requests per second, the time it would take to make one thousand requests would jump from two minutes to five days. This pretty much renders the brute force attack tool useless. An incrementing delay also solves the problem of the attacker holding the password constant and varying the username. Since the system tracks failed login attempts on a user session basis and not an authentication credential basis, the delay logic cannot be bypassed this way.
<cfparam name="session.FailedLogin" default="0" >
<cfset session.FailedLogin = session.FailedLogin +1>
<cfset createObject("java", "java.lang.Thread").sleep(JavaCast("int", session.FailedLogin*500))>
What are the two issues? Email me if you don't want to post here.
But in answer to your question, yes something exactly like you posted.
thanks