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.
Important BlogCFC Update
Raymond Camden said: I'd say you are. :) createObject is not a security threat. Some hosts shut it down because they thin...
[More]
Important BlogCFC Update
Don said: Hmmmm. Problem being that without createObject they don't work. Actually, they don't work at all. CF...
[More]
Important BlogCFC Update
Raymond Camden said: I will, respectfully, disagree with you on the createObject. Most hosts do NOT block it as blocking ...
[More]
Important BlogCFC Update
Don said: HA! Found you here. :) Okay, here are my comments on this blog software. It is a pain. Let me explai...
[More]
Important BlogCFC Update
Raymond Camden said: 1) FCK - I can't. I don't use it.
2) Turn off commenting: No, you could with a few small hacks. Lik...
[More]
RSS
Search
Subscribe
Enter your email address to subscribe to this blog.
SVN Access
You can download the latest version from Subversion, use this url:
http://svn.riaforge.org/blogcfc
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