brute force protection

[brian downing]

I want a brute force protector for logins that will:

1. block based on username(eventually add ip)

2. store info about failed login to db(username, pwd, user-agent, etc)

3. When locked will tell user that they are locked out

I looked at the following apps:

1. http://code.google.com/p/django-brutebuster/ In decorators.py the method returns None when locked so the user gets the “Please enter a correct username and password. Note that both fields are case-sensitive”. I want the user to know the account is locked out.

2. https://github.com/alexkuhl/django-failedloginblocker In decorators.py the method raises an exception which means if debug=False the user will see a 500 error.

3. http://code.google.com/p/django-axes/ This doesn't include the user (has ip and user-agent). In decorators.py I'm not sure how to get the user name. Also I'm concerned about the approach of trying to log someone in and then logging them out if the account is locked. I like the approaches of #1 and #2 where they first check if the account is locked before trying to log them in.

For #1 and #2 I looked into adding the error to the form and I found this post Django - Error Message in Custom Auth Backend that says overwrite django.contrib.auth.forms.AuthenticationForm but I'm not sure how to incorporate the new form in the apps.

Does anyone have suggestions about writing a brute force protector that will do the things I want?

I posted this on stackoverflow but didn't get a response.

Brian

[David Fischer]

This has definitely been discussed before[1], but I think it is worth discussing again. This issue has become even more pressing since the password hashing algorithm has increased its computational complexity significantly in 1.4. Because of that increased CPU utilization, a denial of service (DoS) attack should be a lot easier and more devastating.

With that said, there are a number of implications. Sometimes locking out users is not desirable since it opens a user up to DoS -- especially if some of the usernames are public. Also, this sort of thing is handled much more efficiently at the web server level as opposed to the application level. Your production web server probably has a good way to throttle requests. The Django security docs[2] mention this.

I'm +1 about getting some sort of throttler into core (or contrib rather), but I think this type of thing needs to be very tunable since different people will have wildly different requirements. A sprint at Djangocon maybe?

[1] https://groups.google.com/d/topic/django-developers/cYd-8C-3wFQ/discussion
[2] https://docs.djangoproject.com/en/1.4/topics/security/#id1

[Amyth Arora]

I agree to David, it is much better to do this at a server level instead of application level. If you want your app to take care of it, i think django-axes is the best solution, you'll just need to customize a few bits according to your needs. Even django-lockout is worth having a look.

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/UxXiAVZKxe0J.

To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

--
Thanks & Regards
----------------------------

Amyth [Admin - Techstricks]
Email - aroras....@gmail.com, ad...@techstricks.com
Twitter - @a_myth_________
http://techstricks.com/

[brian]

For my long term plans I want it to be app based. To start with I want to give 3 tries and then lockout. For my use case this will work. Long term I like to add IP and move over to a captcha after 3 tries and a delay like 2^tryNumber.

Brian