Security Update
I just released a security update. It address two issues. Please download like - um - now.
I just released a security update. It address two issues. Please download like - um - now.
For the latest packaged version, you may download the zip from here. For the very latest version, however, you should use the Subversion repository.
For general questions and support, please use the BlogCFC Forums.
You can download the latest version from Subversion, use this url: http://svn.riaforge.org/blogcfc
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
Question for folks concerning RTEs
Steve W said: Disregard my previous post. The only way I am able to get it to work consistently is to be in sourc...
[More]
Question for folks concerning RTEs
Steve W said: It seems to work just fine. I am transitioning another blog to use ckeditor and will post a details...
[More]
Question for folks concerning RTEs
Raymond Camden said: The big question is - what about code blocks?
[More]
Question for folks concerning RTEs
Steve W said: I have successfully added CKEditor to BlogCFC with no problems. It requires almost no work. All yo...
[More]
BlogCFC will never have an installer. Ever. Until today...
Raymond Camden said: Does removing the ( and ) in the WITH clause make it work?
[More]
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