Michael Furman (Migrated from SEC-1845) said:
Hi! The simplest way to block Brute Force Attacks is to add the delay before the next authentication in case of the failed authentication. See https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks Please find attached patch that allows to do it. Probably it will be required to modify the configuration and the configuration. Best regards, Michael
Comment From: spring-projects-issues
Michael Furman said:
Probably it will be required to modify the configuration and the documentation.
Comment From: spring-projects-issues
Luke Taylor said:
Hi Michael. You are still using Spring Security, eh :) ?
I'd prefer not to add something like this to the main authentication filters as there are potentially different approaches that an application might want to take to mitigate repeated attempts at authentication. A better option would be to implement the behaviour in a custom AuthenticationFailureHandler to support your specific requirements. That way it is pluggable rather than permanently built-in.
Comment From: spring-projects-issues
Michael Furman said:
Hi Luke! I still use and enjoy Spring Security. Finally I have found time to contribute :)
BTW, please look also SEC-1844 – may be it will be good to add it to Spring Security 3.1.
Regarding AuthenticationFailureHandler – I get your point. I will try to provide patch ASAP.
Best regards, Michael
Comment From: spring-projects-issues
Michael Furman said:
Luke, I wonder what is better way: to add the additional property to SimpleUrlAuthenticationFailureHandler or to override it and to create the new SimpleUrlWithBlockingBruteForceAttacksAuthenticationFailureHandler Best regards, Michael
Comment From: spring-projects-issues
Luke Taylor said:
To be honest, I'm not sure I would add it as a specific feature. I think there are too many different approaches to dealing with brute-force attacks and people should generally plug in what suits their requirements. Adding a delay by overriding one of the existing failure handlers is straightforward. In other cases, people might want to do it in the AuthenticationProvider or even the AuthenticationManager. That way it would also apply to authentication strategies which don't support an AuthenticationFailureHandler.
Comment From: spring-projects-issues
Michael Furman said:
The AuthenticationFailureHandler which performs sleep() on unsuccessful authentication to block Brute Force Attacks.
Comment From: spring-projects-issues
Michael Furman said:
Luke, I have attached BlockingBruteForceAttacksAuthenticationFailureHandler - AuthenticationFailureHandler which performs sleep() on unsuccessful authentication to block Brute Force Attacks.
Regarding the approach for Blocking Brute Force Attacks – I am partially agree with you.
The simplest ways that will not allow Brute Force Attacks for robots – it is delay with the response on unsuccessful authentication. See https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
I do believe that it should be added by default to Spring Security.
It think the better way than the attached file is to add the functionality to SimpleUrlAuthenticationFailureHandler. In this case the
I can do it if you agree with the approach and will create appropriate patch.
BTW, please look also SEC-1844 – may be it will be good to add it to Spring Security 3.1.
Best regards, Michael
Comment From: spring-projects-issues
Patrick Wiederkehr said:
Even Tomcat managed to include a standard brute force defending feature: http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#LockOutRealm
In a "I implmement it on my own version", there are plenty of things that can go wrong.. So long, it makes sense to have something "solid".
Comment From: marcusdacoregio
@rwinch is this something that we have an idea already if we are going to do or not? Maybe we should close it since there are many different approaches to prevent brute force attacks by extending what Spring Security already provides
Comment From: rwinch
Thanks @marcusdacoregio I don't think we want to add a delay as this can cause a DoS attack by blocking the available threads for servicing requests.