Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha
> I was thinking of adding a recaptcha implementation, based on the work > of others, if that would work with licenses. But probably that choice > would indeed introduce an external (unwanted) dependency. Yeah... it's really a tricky problem. That solution is probably best as an external app. Some users deploy Django apps with no net access at all. > About ticket 16860, I believe that to be over my head for now. In your > opinion, is that ticket tied to the User discussion, about a more > flexible/abstract User model (ticket 3011)? It's tied to it, but 3011 is really hairy, and I believe we can do good work in 16860 with or without the changes under discussion in 3011. I don't know when we will sort out 3011, but the stuff in 16860 can happen on a different timeframe. > And/Or do you believe we have to deal with database migration first? That would be nice, but I think we can work with what we currently have. -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha
Hi Paul, Thanks for your review and remarks. I will think on it more, and will write a longer response later. For the moment just this quick reponse: I was thinking of adding a recaptcha implementation, based on the work of others, if that would work with licenses. But probably that choice would indeed introduce an external (unwanted) dependency. About ticket 16860, I believe that to be over my head for now. In your opinion, is that ticket tied to the User discussion, about a more flexible/abstract User model (ticket 3011)? And/Or do you believe we have to deal with database migration first? Wim On Oct 2, 9:21 am, Paul McMillan wrote: > My sense is that you're conflating 2 kinds of protection here because > you haven't made a decision. Do you want to propose rate limiting, or > a captcha? Answers to your points depend on that. > > Prior to more specific work on this matter (and before anything can be > included in core), we need to address the issues in 16860. The generic > groundwork must be done first. It would be helpful to examine this > proposal in light of those concerns. What hooks does Django need to > provide to allow this to be implemented cleanly as a third-party > installable? > > This needs to be pluggable because (no matter what we include), it > won't meet the requirements for a sizable subset of Django's users > (many of whom have very explicit requirements). > > > Points 1-3 > > Our protection should be on by default if we include it in Django at > all. This means that the default configuration will be universal > enough that it doesn't get in the way for most installations. > > > 4. After x failed login attempts, protection kicks in. x is a > > configurable amount of times, which by default is 3? > > 3 is too few for a default on a general user-facing site. Brute force > attempts try hundreds of passwords. If normal users see this > protection with any regularity, people will turn it off. > > > 5. Failed logins are either stored in a database (which works well for > > small systems and protects against slow distributed attacks), or in > > memory (for large systems). Default: use the database? Because most > > users operate on small systems? > > Probably the database. An extra column on users would be the most > obvious place, but it's a no-go because we don't have migrations and > this functionality should be separately pluggable anyway. We would > need to ship with a default set to off in the base settings file, and > explicitly set it on for new projects. If it adds database columns, > that might be an argument for shipping with it disabled. > > > 6. We protect against the following scenarios: > > a. Login attempts coming from many IP-addresses and targeting a > > single user account; > > b. From a single IP-address, targeting a single user; > > c. Single IP-address, more than one user. > > Case 6a and - in a lesser extent - 6b are strong indicators for a > > brute force attack. Case 6c might be brute force, but might also be > > triggered by many users behind a proxy. > > These are all attack vectors. There's also multiple IP multiple > account slow brute force, and many other variations. Any of these > options is going to need to be quite configurable to work for most > Django users. > > > 7. Protection may consist of: > > a. denying access for x minutes for a given user or IP-address. x > > is configurable, and by default: 5 minutes? > > Rate limiting is more user friendly than a hard cutoff like this. The > hard cutoff is easier to explain to a user, though. This allows a DoS > attack against specific users. > > > b. adding a sleeptime to login requests (mentioned several times, > > but sounds very weak to me, because it can be easily passed by opening > > a new connection?). > > Absolutely no. Adding sleep() anywhere in Django opens nasty DoS > avenues. Sleep ties up workers for no reason. > > > c. logging it, and/or notifying the admin > > d. adding a captcha to login form > > Which captcha do you propose? Is there a good one which does not add > external dependencies? We can't require compiled dependencies like PIL > out of the box. > > > 8. Protection should be configurable as well. By default: use a > > captcha? Using a captcha prevents an attacker from using the denial > > trigger for a DoS-attack. > > Captchas do that. They also introduce usability issues. Do you have a > pure-python captcha which is also ADA compliant? How do you recommend > we balance the difficulty (for both humans and robots) of the captcha? > > > 9. Rate limitors should be generably applicable, to all views. > > Yes. This is why they are probably best viewed as a separate feature. > > > 10. Final question: > > Should this be in Django contrib? I argue in favor, in order to > > protect the innocent and keep everyone safe. > > I agree that Django should ship some form of login protection. > > > django.contrib.security > > seems a proper place to me. > > For rate limiting or
Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha
My sense is that you're conflating 2 kinds of protection here because you haven't made a decision. Do you want to propose rate limiting, or a captcha? Answers to your points depend on that. Prior to more specific work on this matter (and before anything can be included in core), we need to address the issues in 16860. The generic groundwork must be done first. It would be helpful to examine this proposal in light of those concerns. What hooks does Django need to provide to allow this to be implemented cleanly as a third-party installable? This needs to be pluggable because (no matter what we include), it won't meet the requirements for a sizable subset of Django's users (many of whom have very explicit requirements). > Points 1-3 Our protection should be on by default if we include it in Django at all. This means that the default configuration will be universal enough that it doesn't get in the way for most installations. > 4. After x failed login attempts, protection kicks in. x is a > configurable amount of times, which by default is 3? 3 is too few for a default on a general user-facing site. Brute force attempts try hundreds of passwords. If normal users see this protection with any regularity, people will turn it off. > 5. Failed logins are either stored in a database (which works well for > small systems and protects against slow distributed attacks), or in > memory (for large systems). Default: use the database? Because most > users operate on small systems? Probably the database. An extra column on users would be the most obvious place, but it's a no-go because we don't have migrations and this functionality should be separately pluggable anyway. We would need to ship with a default set to off in the base settings file, and explicitly set it on for new projects. If it adds database columns, that might be an argument for shipping with it disabled. > 6. We protect against the following scenarios: > a. Login attempts coming from many IP-addresses and targeting a > single user account; > b. From a single IP-address, targeting a single user; > c. Single IP-address, more than one user. > Case 6a and - in a lesser extent - 6b are strong indicators for a > brute force attack. Case 6c might be brute force, but might also be > triggered by many users behind a proxy. These are all attack vectors. There's also multiple IP multiple account slow brute force, and many other variations. Any of these options is going to need to be quite configurable to work for most Django users. > 7. Protection may consist of: > a. denying access for x minutes for a given user or IP-address. x > is configurable, and by default: 5 minutes? Rate limiting is more user friendly than a hard cutoff like this. The hard cutoff is easier to explain to a user, though. This allows a DoS attack against specific users. > b. adding a sleeptime to login requests (mentioned several times, > but sounds very weak to me, because it can be easily passed by opening > a new connection?). Absolutely no. Adding sleep() anywhere in Django opens nasty DoS avenues. Sleep ties up workers for no reason. > c. logging it, and/or notifying the admin > d. adding a captcha to login form Which captcha do you propose? Is there a good one which does not add external dependencies? We can't require compiled dependencies like PIL out of the box. > 8. Protection should be configurable as well. By default: use a > captcha? Using a captcha prevents an attacker from using the denial > trigger for a DoS-attack. Captchas do that. They also introduce usability issues. Do you have a pure-python captcha which is also ADA compliant? How do you recommend we balance the difficulty (for both humans and robots) of the captcha? > 9. Rate limitors should be generably applicable, to all views. Yes. This is why they are probably best viewed as a separate feature. > 10. Final question: > Should this be in Django contrib? I argue in favor, in order to > protect the innocent and keep everyone safe. I agree that Django should ship some form of login protection. > django.contrib.security > seems a proper place to me. For rate limiting or captcha? The former might belong in core.ratelimit. The captcha is probably a pluggable related to contrib.auth. > There are several rate-limiting > implementations in the wild, but unfortunately they are not often > used. For example, compare the numbers on django-packages for django- > axes, brutebuster and ratelimitcache against a commonly used > application like south or django-debug-toolbar. Yep. This is why we do need to ship something with Django. But we need to be sure that we ship a careful, complete implementation, because once we make a decision about the interface, we have to support it for a long time. This is why many parts of contrib started as external projects and stayed that way until there were clear winners. If we can build the hooks that make it easy to build this kind of functionality, we can g
Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha
Hello, Thanks for the pointers. Based on the previous discussion and the comments at Simon Willison's blog on ratelimitcache, here is a first draft of my proposal: 1. Considering that Django's admin and default login schemes are currently unprotected against brute force attacks by default, and 2. Many users implement Django out of the box with an admin open to brute force attacks, 3. We aim to protect Django users and to make their projects safe by supplying an optional brute force protection mechanism. Which by default is: on? Or off? 4. After x failed login attempts, protection kicks in. x is a configurable amount of times, which by default is 3? 5. Failed logins are either stored in a database (which works well for small systems and protects against slow distributed attacks), or in memory (for large systems). Default: use the database? Because most users operate on small systems? 6. We protect against the following scenarios: a. Login attempts coming from many IP-addresses and targeting a single user account; b. From a single IP-address, targeting a single user; c. Single IP-address, more than one user. Case 6a and - in a lesser extent - 6b are strong indicators for a brute force attack. Case 6c might be brute force, but might also be triggered by many users behind a proxy. 7. Protection may consist of: a. denying access for x minutes for a given user or IP-address. x is configurable, and by default: 5 minutes? b. adding a sleeptime to login requests (mentioned several times, but sounds very weak to me, because it can be easily passed by opening a new connection?). c. logging it, and/or notifying the admin d. adding a captcha to login form 8. Protection should be configurable as well. By default: use a captcha? Using a captcha prevents an attacker from using the denial trigger for a DoS-attack. 9. Rate limitors should be generably applicable, to all views. 10. Final question: Should this be in Django contrib? I argue in favor, in order to protect the innocent and keep everyone safe. django.contrib.security seems a proper place to me. There are several rate-limiting implementations in the wild, but unfortunately they are not often used. For example, compare the numbers on django-packages for django- axes, brutebuster and ratelimitcache against a commonly used application like south or django-debug-toolbar. I would be very glad to hear your comments. Please let me know of anything else I did not cover and should have, and please let me know your answers to the many questions I raised. Thanks for your help! Goodnight to you, Wim -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha
(to complete my thought from the previous prematurely sent email) The bigger problem is that ANY rate-limiting framework is going to need heavy customization to work for all of the different ways Django is deployed. One size will definitely not fit all in this case. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha
Since you mention passwords specifically, I think this conversation is related to #16860. Throttling of passwords / adding captchas definitely falls under that ticket. https://code.djangoproject.com/ticket/16860 We probably should include a more general rate limiting framework (or at the very least, better instructions for configuring this in common webservers). Unfortunately, how to do this well is a REALLY hard problem. There's django-axes as well as Simon Willison's ratelimitcache. Neither of them are perfectly ideal. The bigger problem is that ANY rate-limiting framework is going to need At the moment, if your login field is not rate-limited, that is a configuration mistake which is between you and your webserver, and is not within the realm of what Django tries to do. We need to be careful not to re-implement functionality that is better left to other parts of the stack. -Paul On Thu, Sep 29, 2011 at 4:05 PM, Wim Feijen wrote: > Thanks guys for the support. > > For reference, there is a previous thread "Brute force attacks", here: > http://groups.google.com/group/django-developers/browse_thread/thread/71877ef02fb7c054/0b44e048b5bf4b77 > > Which does not mention captcha's btw. > > Luke, I'll think about it, but it will take some time; thanks for the > guidance. > > Wim > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha
Thanks guys for the support. For reference, there is a previous thread "Brute force attacks", here: http://groups.google.com/group/django-developers/browse_thread/thread/71877ef02fb7c054/0b44e048b5bf4b77 Which does not mention captcha's btw. Luke, I'll think about it, but it will take some time; thanks for the guidance. Wim -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha
you don't need to start from scratch as there's https://github.com/codekoala/django-axes -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/iF3qq-pH80sJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha
On 29/09/11 15:06, Wim Feijen wrote: > Would it be a good idea to write a ticket and patch to stop brute > force attacks, either by requiring people to fill in a captcha after > several failed login attempts; or by setting a time delay? If you search the archives of this list you'll find a fairly recent discussion on this. Please read that first. We will need, at the very least, a pluggable solution with a well-defined interface, because we will not find a one-size-fits-all solution. As such, it is not a small feature by any means. It will require significant effort just in terms of proposing the feature. Create a ticket by all means, but I would suggest that a solid proposal should be thoroughly discussed here before you start coding. Regards, Luke -- I teleported home one night With Ron and Sid and Meg, Ron stole Meggie's heart away And I got Sidney's leg (THHGTTG) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha
+1 please On 9/29/11, Wim Feijen wrote: > Hello, > > Would it be a good idea to write a ticket and patch to stop brute > force attacks, either by requiring people to fill in a captcha after > several failed login attempts; or by setting a time delay? > > Mozilla Secure Coding Guidelines recommend in doing so, see: > https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Easy_Quick_Wins > > Google uses a captcha and I favor that approach. > > Would it be a good idea to create a ticket for this, and write a > patch? > > Best regards, > > Wim > > --- > > From the Mozilla Secure Coding Guidelines: > > Account Lockout and Failed Login > Account Lockouts vs login failures should be evaluated based on the > application. In either case, the application should be able to > determine if the password being used is the same one over and over, or > a different password being used which would indicate an attack. > > The error message for both cases should be generic such as: > > Invalid login attempts (for any reason) should return the generic > error message > > The username or password you entered is not valid > > Logging will be critical for these events as they will feed up into > our security event system and we can then take action based on these > events. The application should also take action. Example would be in > the case that the user is being attacked, the application should stop > and/or slow down that user progress by either presenting a captcha or > by doing a time delay for that IP address. Captcha's should be used in > all cases when a limit of failed attempts has been reached. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Sent from my mobile device -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
prevent brute force attacks by acting on several failed logins, for example by using a captcha
Hello, Would it be a good idea to write a ticket and patch to stop brute force attacks, either by requiring people to fill in a captcha after several failed login attempts; or by setting a time delay? Mozilla Secure Coding Guidelines recommend in doing so, see: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Easy_Quick_Wins Google uses a captcha and I favor that approach. Would it be a good idea to create a ticket for this, and write a patch? Best regards, Wim --- >From the Mozilla Secure Coding Guidelines: Account Lockout and Failed Login Account Lockouts vs login failures should be evaluated based on the application. In either case, the application should be able to determine if the password being used is the same one over and over, or a different password being used which would indicate an attack. The error message for both cases should be generic such as: Invalid login attempts (for any reason) should return the generic error message The username or password you entered is not valid Logging will be critical for these events as they will feed up into our security event system and we can then take action based on these events. The application should also take action. Example would be in the case that the user is being attacked, the application should stop and/or slow down that user progress by either presenting a captcha or by doing a time delay for that IP address. Captcha's should be used in all cases when a limit of failed attempts has been reached. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Brute force attacks
Hi Guys, This topic has me crawling out of the woodwork, I would like to contribute to the effort. Can't see this making it into django's core, although I would like to see it there, I think complexities would inhibit beginners and veterans alike, although, it would be nice if it could be configured and enabled. At a minimum, it's going to require a table or two in the auth realm, and additional hooks on the rack. What I would like to see is something akin to a bank's level of security that could be throttled to preference. -Joe -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Brute force attacks
You're right - let's not argue this anymore. We'll work on something and if it makes it into contrib, great, if not - well I guess we're no worse off than we are right now. In the interim I propose that we add a note to http://docs.djangoproject.com/en/dev/topics/auth/ to let users know that brute-force prevention doesn't come out of the box. Does that sound fair? On Mar 8, 4:10 am, Michael Radziej wrote: > On Mon, 7 Mar 2011 18:11:19 -0800 (PST), Rohit Sethi > wrote: > > Luke, I guess the real question is what's the risk of not including it > > out-of-the-box? > > Well, it *is* not included out-of-the-box. The universe has not collapsed. > > While I appreciate your proposal, I don't see the immediate necessity to > stop all other django development. As Russell wrote: Nothing will happen > until somebody gets their hands dirty and writes some code. And the > past has proved that this happens much better independently from the > release cycle of the django core. When a good solution has been found, > it might go into the core. > > It's simply easier to try out various concepts out of the core. > > Kind regards > > Michael -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Brute force attacks
On Mon, 7 Mar 2011 18:11:19 -0800 (PST), Rohit Sethi wrote: > Luke, I guess the real question is what's the risk of not including it > out-of-the-box? Well, it *is* not included out-of-the-box. The universe has not collapsed. While I appreciate your proposal, I don't see the immediate necessity to stop all other django development. As Russell wrote: Nothing will happen until somebody gets their hands dirty and writes some code. And the past has proved that this happens much better independently from the release cycle of the django core. When a good solution has been found, it might go into the core. It's simply easier to try out various concepts out of the core. Kind regards Michael -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Brute force attacks
Luke, I guess the real question is what's the risk of not including it out-of-the-box? What happens if Django users *do not* go out of their way to use a third party tool to protect against brute-forcing? Seems to me that they're likely susceptible in the absence of a network device or service designed to protect against application-layer brute forcing. How many Django auth users implement one of these third party account throttling/lockout plugins today? How many of the developers who do not implement these tools are relying on django.contrib.auth to protect confidential or integral data within their applications? If the vast majority of Django apps using auth have brute-force protection in place already OR they're okay with being susceptible to a script-kiddie attack then there really *isn't* a need for this and we should drop it. My suspicion is that it's probably the opposite but I readily admit I might be wrong. The concerns you bring up are valid - there aren't obvious answers that will work in the vast majority of cases. I'd like to think we can err on the side of being permissive: the vast majority of valid end users should not experience any impact to their authentication. This may not pass an ISO27001 audit but it's going to substantially help protect your application. One of the biggest challenge seems to be configuration, and a real desire not to add more configuration options. I have to plead ignorance here and say that I don't know if you've found other ways around this in the past. You're right that this won't work without configuration options and the ability to turn-off / use a different plugin. Perhaps another option to explore is to bundle this, along with other important security measures such as password complexity configuration, into a security package for Django rather than adding it to contrib. I would prefer not to go down this route for something as important as authentication throttling as I think many Django users believe that Django's inherent security is good enough for their needs. Again, please correct me if my assumptions here are wrong. On Mar 7, 6:48 pm, Luke Plant wrote: > On 04/03/11 21:56, Rohit Sethi wrote: > > > Hi all, I wanted to revisit a key security discussion. Brute force > > attacks are the 7th most prevalent attack by number of incidents in > > the Web Hacking Incidents Database (http://projects.webappsec.org/w/ > > page/13246995/Web-Hacking-Incident-Database), which tracks publicly > > disclosed breaches in web application. This is ultimately because many > > applications do not have provisions to prevent brute-forcing. Django’s > > out of the box admin-site authentication is very awesome – so awesome, > > in fact, that inevitably people have and will continue to use it for > > more than just administrative users. Clearly Django takes > > authentication seriously. Can we revisit the idea of protecting > > against brute force authentication out of the box? (http:// > > groups.google.com/group/django-developers/browse_thread/thread/ > > 7559145e8c85d8c/b96c9a81e97f333b?lnk=gst&q=account > > +lockout#b96c9a81e97f333b). > > For me, since you can implement this as an external app for most cases, > the question is: why should we include something in core or contrib? > > The answer must be either: > > 1) we need this out-of-the-box in the normal case. > 2) having multiple solutions hinders web development, rather than > fostering beneficial competition that can evolve faster than > Django's release cycle. > > Regarding 1), if we aim for something out-of-the-box, we *have* to make > all kinds of decisions, as already discussed, like: > > - on what basis to we detect brute force attacks? > > - what rates do we limit to? > > - what action do we actually take when we detect attacks? > > - where do we store failed attempts? (database, cache?) > > Most of the answers would be inappropriate in large number of cases, and > we would then need a whole bunch of settings to allow customisation to > these. At the very least, we would need to be able to disable the whole > thing, and use something else. > > Regarding 2), I don't see that having multiple solutions, even multiple > solutions in a single project, is a problem, unlike something like the > 'messages' framework that was added to contrib, where there is obvious > benefit from a single solution that provides most of the features that > most apps need. > > Further, I envisage that adding a solution to core/contrib might tend to > make it *harder* to add a custom solution, since bundled apps (e.g. the > admin) will use the bundled solution. If that solution uses view > decorators like Simon's ratelimitc
Re: Brute force attacks
On 04/03/11 21:56, Rohit Sethi wrote: Hi all, I wanted to revisit a key security discussion. Brute force attacks are the 7th most prevalent attack by number of incidents in the Web Hacking Incidents Database (http://projects.webappsec.org/w/ page/13246995/Web-Hacking-Incident-Database), which tracks publicly disclosed breaches in web application. This is ultimately because many applications do not have provisions to prevent brute-forcing. Django’s out of the box admin-site authentication is very awesome – so awesome, in fact, that inevitably people have and will continue to use it for more than just administrative users. Clearly Django takes authentication seriously. Can we revisit the idea of protecting against brute force authentication out of the box? (http:// groups.google.com/group/django-developers/browse_thread/thread/ 7559145e8c85d8c/b96c9a81e97f333b?lnk=gst&q=account +lockout#b96c9a81e97f333b). For me, since you can implement this as an external app for most cases, the question is: why should we include something in core or contrib? The answer must be either: 1) we need this out-of-the-box in the normal case. 2) having multiple solutions hinders web development, rather than fostering beneficial competition that can evolve faster than Django's release cycle. Regarding 1), if we aim for something out-of-the-box, we *have* to make all kinds of decisions, as already discussed, like: - on what basis to we detect brute force attacks? - what rates do we limit to? - what action do we actually take when we detect attacks? - where do we store failed attempts? (database, cache?) Most of the answers would be inappropriate in large number of cases, and we would then need a whole bunch of settings to allow customisation to these. At the very least, we would need to be able to disable the whole thing, and use something else. Regarding 2), I don't see that having multiple solutions, even multiple solutions in a single project, is a problem, unlike something like the 'messages' framework that was added to contrib, where there is obvious benefit from a single solution that provides most of the features that most apps need. Further, I envisage that adding a solution to core/contrib might tend to make it *harder* to add a custom solution, since bundled apps (e.g. the admin) will use the bundled solution. If that solution uses view decorators like Simon's ratelimitcache, we've hardcoded something that might be inappropriate. I don't see the point of trying to add this to Django unless we can answer these questions, but from the sounds of the thread so far, I suspect we cannot provide sensible defaults with enough customization hooks to make it worthwhile. In the end, I'm afraid this will end up as one more example of Django "badteries" <http://www.scribd.com/doc/37113340/Why-Django-Sucks-and-How-we-Can-Fix-it> (That presentation of Eric's is really good, BTW, video here <http://djangocon.blip.tv/file/4112452/>) Regards, Luke -- "Despair: It's always darkest just before it goes pitch black." (despair.com) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Brute force attacks
On 7.3.2011 г. 22:09 ч., Eric Hutchinson wrote: I would just like to point out that a lot of my users all are behind various nats, so my webapp typically sees only a few ips that have valid users on them, and i have users whom i have to remind of their password on a daily basis. it could lead to a couple of dozen people being throttled for one person who doesn't know their caps key being lit up green is why their password isn't working i'm not saying this is a situation the default should take care of, but something to keep in mind when designing any backend classes, so that just the bit that determines the cache key or whatever should be override-able. I believe that a block against the combo IP+Usrname takes care of this problem. It is enough to block most of the non-distributed attacks (unless the attacker is bruteforcing thousands of usernames), and it would provide significant resistance against distributed attacks as well. -- Best Regards, Emil Filipov Cyber Security Consulting Ltd. http://csc.bg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Brute force attacks
I would just like to point out that a lot of my users all are behind various nats, so my webapp typically sees only a few ips that have valid users on them, and i have users whom i have to remind of their password on a daily basis. it could lead to a couple of dozen people being throttled for one person who doesn't know their caps key being lit up green is why their password isn't working i'm not saying this is a situation the default should take care of, but something to keep in mind when designing any backend classes, so that just the bit that determines the cache key or whatever should be override-able. On Mar 7, 1:01 pm, Rohit Sethi wrote: > Looks like we're on the same page. I agree that we need something > lightweight designed to repel brute force from a single IP. Something > designed to detect distributed attacks would require more overhead and > monitoring and probably doesn't belong in core. That said, I believe > we should think about logging error messages using OWASP AppSensor > detection point codes (http://www.owasp.org/index.php/ > OWASP_AppSensor_Project#tab=Detection_Points) so that a third party > monitoring tool can detect an attack on the application. Perhaps one > day we could extend this standardized security logging to > authorization failures as well. > > We balance against DoS by slow incrementing the timeout period. We'll > certainly need to experiment with this to get sensible values, but I'd > suggest thinking about doubling the timeout period for every > successive failed attempt starting from some configurable value such > as 5 seconds up to some configurable maximum such as 4 hours. Ideally > throttling wouldn't kick until at least three failed attempts (also > configurable). To reiterate, all numbers above are just examples - > we'll need to test in some real world conditions to figure out the > best default values. > > On Mar 6, 7:46 pm, Paul McMillan wrote: > > > > > > > > > I go back and forth on this issue. Unlike CSRF, there's never going to > > be a one size fits all solution for this type of problem. Different > > organizations have widely varying requirements, and while I prefer > > rate limits, that won't satisfy the auditor whose checklist requires > > permanent lockout after X attempts. > > > That said, Django's current approach of "figure something out > > yourself" means that most installs don't get any work in this realm. > > We can't defend against every attack scenario, but if we can improve > > the most common areas, it will be a substantial gain. > > > I'm quite interested in working to get better protection into core. I > > agree with Rohit that throttling/rate-limiting is going to be where > > Django finds a good balance between intrusiveness and security. In > > larger systems, this task is often taken care of by the firewall in a > > generic one-size-fits-all fashion, but if Django is doing the > > limiting, we can provide more specific protection, especially for > > users who don't have fine-grained control over their firewall. > > > If we build a rate limiter into core, it will encourage users to make > > use of it in their own projects. It will also allow us to rate limit > > other areas of core to improve security - passwords are far from the > > only thing susceptible to brute force, and the same framework may be > > useful to prevent or discourage DoS. > > > We need to be careful to provide permissive defaults. Leave the knobs > > exposed for organizations which require draconian measures, but for > > the average user, convenience trumps security. > > > At the expense of creating more work, I think that we need to agree on > > several facets of the problem before we go writing code: > > > 1) Which attack scenarios do we protect against? > > > A single machine high-rate attack? A high-rate distributed attack? A > > slow distributed attack? > > > The first of these is the most likely attack - it's easy to implement, > > and doesn't require extensive resources or patience. Defenses against > > it will also apply (to a lesser extent) in the case of a high-rate > > distributed attack. Measures like locking accounts after a number of > > login failures prevent the slow attack, but they inconvenience users > > and open a very nasty avenue for DoS. I don't know of measures Django > > could take which would provide an acceptable balance between > > completely preventing this attack and avoiding inconveniencing users. > > > 2) How do we balance protection against DoS concerns? > > > Since Django installa
Re: Brute force attacks
Looks like we're on the same page. I agree that we need something lightweight designed to repel brute force from a single IP. Something designed to detect distributed attacks would require more overhead and monitoring and probably doesn't belong in core. That said, I believe we should think about logging error messages using OWASP AppSensor detection point codes (http://www.owasp.org/index.php/ OWASP_AppSensor_Project#tab=Detection_Points) so that a third party monitoring tool can detect an attack on the application. Perhaps one day we could extend this standardized security logging to authorization failures as well. We balance against DoS by slow incrementing the timeout period. We'll certainly need to experiment with this to get sensible values, but I'd suggest thinking about doubling the timeout period for every successive failed attempt starting from some configurable value such as 5 seconds up to some configurable maximum such as 4 hours. Ideally throttling wouldn't kick until at least three failed attempts (also configurable). To reiterate, all numbers above are just examples - we'll need to test in some real world conditions to figure out the best default values. On Mar 6, 7:46 pm, Paul McMillan wrote: > I go back and forth on this issue. Unlike CSRF, there's never going to > be a one size fits all solution for this type of problem. Different > organizations have widely varying requirements, and while I prefer > rate limits, that won't satisfy the auditor whose checklist requires > permanent lockout after X attempts. > > That said, Django's current approach of "figure something out > yourself" means that most installs don't get any work in this realm. > We can't defend against every attack scenario, but if we can improve > the most common areas, it will be a substantial gain. > > I'm quite interested in working to get better protection into core. I > agree with Rohit that throttling/rate-limiting is going to be where > Django finds a good balance between intrusiveness and security. In > larger systems, this task is often taken care of by the firewall in a > generic one-size-fits-all fashion, but if Django is doing the > limiting, we can provide more specific protection, especially for > users who don't have fine-grained control over their firewall. > > If we build a rate limiter into core, it will encourage users to make > use of it in their own projects. It will also allow us to rate limit > other areas of core to improve security - passwords are far from the > only thing susceptible to brute force, and the same framework may be > useful to prevent or discourage DoS. > > We need to be careful to provide permissive defaults. Leave the knobs > exposed for organizations which require draconian measures, but for > the average user, convenience trumps security. > > At the expense of creating more work, I think that we need to agree on > several facets of the problem before we go writing code: > > 1) Which attack scenarios do we protect against? > > A single machine high-rate attack? A high-rate distributed attack? A > slow distributed attack? > > The first of these is the most likely attack - it's easy to implement, > and doesn't require extensive resources or patience. Defenses against > it will also apply (to a lesser extent) in the case of a high-rate > distributed attack. Measures like locking accounts after a number of > login failures prevent the slow attack, but they inconvenience users > and open a very nasty avenue for DoS. I don't know of measures Django > could take which would provide an acceptable balance between > completely preventing this attack and avoiding inconveniencing users. > > 2) How do we balance protection against DoS concerns? > > Since Django installations are usually public-facing, Denial of > Service issues are often a larger concern than brute force attacks > (the entire site being unavailable vs. some number of compromised user > accounts) I strongly oppose the addition of any code which makes > Django significantly more vulnerable to DoS out of the box, even if it > does improve security. > > 3) What is the appropriate response to an attacker? > > Lock the account? Deny access to the whole application? For how long? > Log the attack? At what threshold? We rapidly get into areas that are > in the domain of a full-blown Intrusion Detection System. I think that > Django needs a very minimal set of features in this realm. Log the > attack when over a certain threshold (and log verbosity), block the IP > for a limited period of time, and move on. > > In light of these issues, I think that the appropriate solution for > core will be: > > * lightweight - we can't compromise pe
Re: Brute force attacks
I go back and forth on this issue. Unlike CSRF, there's never going to be a one size fits all solution for this type of problem. Different organizations have widely varying requirements, and while I prefer rate limits, that won't satisfy the auditor whose checklist requires permanent lockout after X attempts. That said, Django's current approach of "figure something out yourself" means that most installs don't get any work in this realm. We can't defend against every attack scenario, but if we can improve the most common areas, it will be a substantial gain. I'm quite interested in working to get better protection into core. I agree with Rohit that throttling/rate-limiting is going to be where Django finds a good balance between intrusiveness and security. In larger systems, this task is often taken care of by the firewall in a generic one-size-fits-all fashion, but if Django is doing the limiting, we can provide more specific protection, especially for users who don't have fine-grained control over their firewall. If we build a rate limiter into core, it will encourage users to make use of it in their own projects. It will also allow us to rate limit other areas of core to improve security - passwords are far from the only thing susceptible to brute force, and the same framework may be useful to prevent or discourage DoS. We need to be careful to provide permissive defaults. Leave the knobs exposed for organizations which require draconian measures, but for the average user, convenience trumps security. At the expense of creating more work, I think that we need to agree on several facets of the problem before we go writing code: 1) Which attack scenarios do we protect against? A single machine high-rate attack? A high-rate distributed attack? A slow distributed attack? The first of these is the most likely attack - it's easy to implement, and doesn't require extensive resources or patience. Defenses against it will also apply (to a lesser extent) in the case of a high-rate distributed attack. Measures like locking accounts after a number of login failures prevent the slow attack, but they inconvenience users and open a very nasty avenue for DoS. I don't know of measures Django could take which would provide an acceptable balance between completely preventing this attack and avoiding inconveniencing users. 2) How do we balance protection against DoS concerns? Since Django installations are usually public-facing, Denial of Service issues are often a larger concern than brute force attacks (the entire site being unavailable vs. some number of compromised user accounts) I strongly oppose the addition of any code which makes Django significantly more vulnerable to DoS out of the box, even if it does improve security. 3) What is the appropriate response to an attacker? Lock the account? Deny access to the whole application? For how long? Log the attack? At what threshold? We rapidly get into areas that are in the domain of a full-blown Intrusion Detection System. I think that Django needs a very minimal set of features in this realm. Log the attack when over a certain threshold (and log verbosity), block the IP for a limited period of time, and move on. In light of these issues, I think that the appropriate solution for core will be: * lightweight - we can't compromise performance here. The solution should be memory-based, and should not write to the database or disk in most cases. I'm perfectly fine with requiring caching to be enabled to get protection. * generic - we should be rate limiting other areas of core, and it makes sense to provide a way for developers to easily limit their own applications. * limited in scope - Django includes many batteries, but it shouldn't include a full-blown IDS. Throttling and logging for events significantly outside the norm are enough protection. Anything more complex becomes application specific. * pluggable - we can't be all things for all people. We need to design an interface that is flexible enough to allow people to implement their own particular set of rules. We do this already in other areas: databases, caching, sessions, etc. If we can provide a good generic interface for this, we can include other backends with different behaviors as they evolve in the community. So, the tl;dr is that Django needs to include a simple rate limiting component that is trivial to enable to discourage many brute-force attacks. I'd like to help make this happen. -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Brute force attacks
Ok, we'll go ahead with researching this. Expect to hear back from us within the next 2-3 weeks (if not this upcoming week) Thanks, Rohit On Mar 5, 8:40 am, Rohit Sethi wrote: > Hi Russell, here are my thoughts on your points: > > 1. I do believe there should be something enabled by default. Some > security conscious developers will go out of there way to integrate a > third party plugin but I believe (and I may be wrong) that many > developers just assume the out-of-the-box authentication is secure > enough to meet their needs. I say this after 6.5 years of application > security consulting and addressing common misconceptions about web app > frameworks repeatedly over the years. This thread has shown that there > has indeed been some policy debate, however I think you'll notice in > the thread Shawn was simply referring to an audit finding - probably > taken from a checklist audit - but as Richard and Emil (and others in > the previous thread) point out this could actually lead to a DoS > vulnerability without appropriate monitoring. I'd strongly advocate > using a throttling mechanism, with the ability to turn it off and > replace with a third party plug-in if somebody desires. > > 2. I don't have an immediate answer on this. We can investigate and > come up with a proposal before we start developing / integrating > > 3. I think the the hashing talk was specifically about stolen stored > credentials - in particular, about being able to determine many > passwords from a table of stolen hashes. For brute force protection > against a single account, you'd have a very slow authentication > process to make it infeasible for somebody to try the top 500 > passwords on a single user account. For example, if it took 3 seconds > per authentication it would take less than half an hour to perform > this brute forcing (http://www.whatsmypass.com/the-top-500-worst- > passwords-of-all-time) usinghttp://sectools.org/crackers.html. > > On Mar 5, 3:43 am, Russell Keith-Magee > wrote: > > > On Sat, Mar 5, 2011 at 5:56 AM, Rohit Sethi wrote: > > > Hi all, I wanted to revisit a key security discussion. Brute force > > > attacks are the 7th most prevalent attack by number of incidents in > > > the Web Hacking Incidents Database (http://projects.webappsec.org/w/ > > > page/13246995/Web-Hacking-Incident-Database), which tracks publicly > > > disclosed breaches in web application. This is ultimately because many > > > applications do not have provisions to prevent brute-forcing. Django’s > > > out of the box admin-site authentication is very awesome – so awesome, > > > in fact, that inevitably people have and will continue to use it for > > > more than just administrative users. Clearly Django takes > > > authentication seriously. Can we revisit the idea of protecting > > > against brute force authentication out of the box? (http:// > > > groups.google.com/group/django-developers/browse_thread/thread/ > > > 7559145e8c85d8c/b96c9a81e97f333b?lnk=gst&q=account > > > +lockout#b96c9a81e97f333b). In particular, the idea of using > > > throttling such ashttp://github.com/simonw/ratelimitcache/or > > >http://code.google.com/p/django-brutebuster/. Would you be willing to > > > discuss further? > > > I'm certainly interested in discussing it. I can't deny that Django's > > auth system doesn't protect against brute-force attacks; if there is > > something that Django can do 'out of the box', then all the better. > > > As with any Django feature proposal, nothing will happen unless > > someone writes the code and drives the issue. This is essentially what > > happened with the thread you referenced -- there wasn't any specific > > resistance to the idea, but there wasn't a specific offer to help (at > > least, not one that was followed up with action), so the discussion > > ended without a resolution. If you're willing to write the code (or > > polish the existing code) and drive the discussions, then this could > > easily become a feature of the 1.4 release. > > > I haven't given this a great deal of thought myself, but here are some > > initial thoughts: > > > * Is this something like CSRF, where there should be One True > > Solution, Enabled By Default, or is it something where a > > backend/plugin interface would be more appropriate? Django has > > historically avoided making policy decisions, and this thread has > > already shown that there are multiple (and policy lawyers exist that > > aren't likely to be flexible on those options). > > > * Where is th
Re: Brute force attacks
Hi Russell, here are my thoughts on your points: 1. I do believe there should be something enabled by default. Some security conscious developers will go out of there way to integrate a third party plugin but I believe (and I may be wrong) that many developers just assume the out-of-the-box authentication is secure enough to meet their needs. I say this after 6.5 years of application security consulting and addressing common misconceptions about web app frameworks repeatedly over the years. This thread has shown that there has indeed been some policy debate, however I think you'll notice in the thread Shawn was simply referring to an audit finding - probably taken from a checklist audit - but as Richard and Emil (and others in the previous thread) point out this could actually lead to a DoS vulnerability without appropriate monitoring. I'd strongly advocate using a throttling mechanism, with the ability to turn it off and replace with a third party plug-in if somebody desires. 2. I don't have an immediate answer on this. We can investigate and come up with a proposal before we start developing / integrating 3. I think the the hashing talk was specifically about stolen stored credentials - in particular, about being able to determine many passwords from a table of stolen hashes. For brute force protection against a single account, you'd have a very slow authentication process to make it infeasible for somebody to try the top 500 passwords on a single user account. For example, if it took 3 seconds per authentication it would take less than half an hour to perform this brute forcing (http://www.whatsmypass.com/the-top-500-worst- passwords-of-all-time) using http://sectools.org/crackers.html. On Mar 5, 3:43 am, Russell Keith-Magee wrote: > On Sat, Mar 5, 2011 at 5:56 AM, Rohit Sethi wrote: > > Hi all, I wanted to revisit a key security discussion. Brute force > > attacks are the 7th most prevalent attack by number of incidents in > > the Web Hacking Incidents Database (http://projects.webappsec.org/w/ > > page/13246995/Web-Hacking-Incident-Database), which tracks publicly > > disclosed breaches in web application. This is ultimately because many > > applications do not have provisions to prevent brute-forcing. Django’s > > out of the box admin-site authentication is very awesome – so awesome, > > in fact, that inevitably people have and will continue to use it for > > more than just administrative users. Clearly Django takes > > authentication seriously. Can we revisit the idea of protecting > > against brute force authentication out of the box? (http:// > > groups.google.com/group/django-developers/browse_thread/thread/ > > 7559145e8c85d8c/b96c9a81e97f333b?lnk=gst&q=account > > +lockout#b96c9a81e97f333b). In particular, the idea of using > > throttling such ashttp://github.com/simonw/ratelimitcache/or > >http://code.google.com/p/django-brutebuster/. Would you be willing to > > discuss further? > > I'm certainly interested in discussing it. I can't deny that Django's > auth system doesn't protect against brute-force attacks; if there is > something that Django can do 'out of the box', then all the better. > > As with any Django feature proposal, nothing will happen unless > someone writes the code and drives the issue. This is essentially what > happened with the thread you referenced -- there wasn't any specific > resistance to the idea, but there wasn't a specific offer to help (at > least, not one that was followed up with action), so the discussion > ended without a resolution. If you're willing to write the code (or > polish the existing code) and drive the discussions, then this could > easily become a feature of the 1.4 release. > > I haven't given this a great deal of thought myself, but here are some > initial thoughts: > > * Is this something like CSRF, where there should be One True > Solution, Enabled By Default, or is it something where a > backend/plugin interface would be more appropriate? Django has > historically avoided making policy decisions, and this thread has > already shown that there are multiple (and policy lawyers exist that > aren't likely to be flexible on those options). > > * Where is the right place for this hook to exist? The two projects > you reference take quite different approaches. Simon's ratelimitcache > is per-view protection -- which means it's easy to accidentally forget > to apply it if you have a custom login, but also more flexible because > you can apply rate limiting to other views, such as an API. Emil's > BruteBuster integrates into the core authentication layer, which is > much more robust, but less immediately flexible for other purposes. > > * Is the
Re: Brute force attacks
On Sat, Mar 5, 2011 at 5:56 AM, Rohit Sethi wrote: > Hi all, I wanted to revisit a key security discussion. Brute force > attacks are the 7th most prevalent attack by number of incidents in > the Web Hacking Incidents Database (http://projects.webappsec.org/w/ > page/13246995/Web-Hacking-Incident-Database), which tracks publicly > disclosed breaches in web application. This is ultimately because many > applications do not have provisions to prevent brute-forcing. Django’s > out of the box admin-site authentication is very awesome – so awesome, > in fact, that inevitably people have and will continue to use it for > more than just administrative users. Clearly Django takes > authentication seriously. Can we revisit the idea of protecting > against brute force authentication out of the box? (http:// > groups.google.com/group/django-developers/browse_thread/thread/ > 7559145e8c85d8c/b96c9a81e97f333b?lnk=gst&q=account > +lockout#b96c9a81e97f333b). In particular, the idea of using > throttling such as http://github.com/simonw/ratelimitcache/ or > http://code.google.com/p/django-brutebuster/. Would you be willing to > discuss further? I'm certainly interested in discussing it. I can't deny that Django's auth system doesn't protect against brute-force attacks; if there is something that Django can do 'out of the box', then all the better. As with any Django feature proposal, nothing will happen unless someone writes the code and drives the issue. This is essentially what happened with the thread you referenced -- there wasn't any specific resistance to the idea, but there wasn't a specific offer to help (at least, not one that was followed up with action), so the discussion ended without a resolution. If you're willing to write the code (or polish the existing code) and drive the discussions, then this could easily become a feature of the 1.4 release. I haven't given this a great deal of thought myself, but here are some initial thoughts: * Is this something like CSRF, where there should be One True Solution, Enabled By Default, or is it something where a backend/plugin interface would be more appropriate? Django has historically avoided making policy decisions, and this thread has already shown that there are multiple (and policy lawyers exist that aren't likely to be flexible on those options). * Where is the right place for this hook to exist? The two projects you reference take quite different approaches. Simon's ratelimitcache is per-view protection -- which means it's easy to accidentally forget to apply it if you have a custom login, but also more flexible because you can apply rate limiting to other views, such as an API. Emil's BruteBuster integrates into the core authentication layer, which is much more robust, but less immediately flexible for other purposes. * Is there overlap here with discussions about password hashing? There was a recent discussion about changing Django's default password hash function to something that was less susceptible to brute-force attacks. This was specifically addressing the fact that SHA1 has known weaknesses, but it only takes a small increase in computational cost to render a brute-force attack impractical. To what extent would introducing a higher-cost hashing function remove the need for specific brute-force protections in auth? Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Brute force attacks
On 03/04/2011 11:56 PM, Rohit Sethi wrote: Hi all, I wanted to revisit a key security discussion. Brute force attacks are the 7th most prevalent attack by number of incidents in the Web Hacking Incidents Database (http://projects.webappsec.org/w/ page/13246995/Web-Hacking-Incident-Database), which tracks publicly disclosed breaches in web application. This is ultimately because many applications do not have provisions to prevent brute-forcing. Django’s out of the box admin-site authentication is very awesome – so awesome, in fact, that inevitably people have and will continue to use it for more than just administrative users. Clearly Django takes authentication seriously. Can we revisit the idea of protecting against brute force authentication out of the box? (http:// groups.google.com/group/django-developers/browse_thread/thread/ 7559145e8c85d8c/b96c9a81e97f333b?lnk=gst&q=account +lockout#b96c9a81e97f333b). In particular, the idea of using throttling such as http://github.com/simonw/ratelimitcache/ or http://code.google.com/p/django-brutebuster/. Would you be willing to discuss further? My development team is willing to contribute whatever is needed to get this done if you think it's fruitful I'm the author of BruteBuster, and I (obviously) think that an easy-to-use bruteforce protection is needed in Django. This being said, I'd suggest to let the code evolve from real-life usage scenarios before being considered for inclusion in the core or in contrib. So, take your pick (or write your own lib), see what works and what doesn't, ask for/implement improvements, then evaluate again. Once there is a clear, proven winner (something like South ;), then ask for inclusion in Django. In the particular case of BruteBuster, feel free to contact me directly with any problems/suggestions (the development of BruteBuster has been largely neglected, due to the code working OK for our needs and lack of interest from other parties). On 03/05/2011 12:22 AM, Shawn Milochik wrote: I have an immediate interest in this discussion. One of my company's Django apps was recently subjected to an external risk assessment team audit. They found the fact that three invalid password attempts didn't lock out the user to be completely unacceptable. ... Also, the thread referred to above discusses throttling, whereas the "recommendation" provided to us by the auditors was user lockout requiring administrator activity (human intervention) to unlock. I find myself doing similar audits often, and from your description it looks like the auditors are simply going over a checklist with prescriptions, without much consideration of what's reasonable. Such kind of restrictive locking is ridiculous for most use-cases. Unless you are a very large corporation/government agency/extremely high security facility, requiring manual intervention from the administrator after 3 failed attempts would simply annoy users and prevent them from doing their work effectively. If there is any enforced password strength, bruteforcing would need *lots* of attempts to succeed. If you hadn't had your coffee in the morning, on the other hand, it is quite easy to trip over the 3 failed attempts limit. What happens if the sysadmin is not available to unlock your account? On a side note, throttling vs locking - you can implement effective locking with throttling (say, throttle rate of 3 attempts in 10**6 minutes), but the opposite is not true. I think it is clear which is the more flexible approach. -- Best Regards, Emil Filipov Cyber Security Consulting Ltd. http://csc.bg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Brute force attacks
On Fri, 2011-03-04 at 17:22 -0500, Shawn Milochik wrote: > the thread referred to above discusses throttling, whereas the > "recommendation" provided to us by the auditors was user lockout > requiring administrator activity (human intervention) to unlock. This *creates* a denial of service vulnerability, especially if your usernames are public. (Otherwise the attacker has to guess at them.) Richard signature.asc Description: This is a digitally signed message part
Re: Brute force attacks
do you guys know about django-axes? (http://code.google.com/p/django-axes/) it allows you to lock out IP or IP/User Agent combo on a given number of failures. On Fri, Mar 4, 2011 at 5:22 PM, Shawn Milochik wrote: > I have an immediate interest in this discussion. One of my company's > Django apps was recently subjected to an external risk assessment team > audit. They found the fact that three invalid password attempts didn't > lock out the user to be completely unacceptable. > > Granted, this is something that I should have applied myself, and if > it were automatically part of Django it would frustrate many > developers because it would inconvenience their users. > > However, considering it's an OWASP concern, and likely a wheel which > will be reinvented repeatedly, I would like to see it in Django. I am > willing to put my time into the effort. If Rohit and his team end up > taking on the project I will coordinate with them to see how I can > help. > > It seems that any implementation of this would require another value > for settings.py, and I know that's something not done lightly. Also, > the thread referred to above discusses throttling, whereas the > "recommendation" provided to us by the auditors was user lockout > requiring administrator activity (human intervention) to unlock. > > So the next question is whether the core dev team is interested in > discussing configurable lockout (number of attempts and human > intervention or timeout to release the lock), throttling, or both. > Then, how to best go about it. > > Incidentally, I'll be at PyCon if anyone wants to get together after > hours to work on this during the main days (I won't be at the > sprints). > > Shawn > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Brendan Smith, IT Specialist National Priorities Project http://www.nationalpriorities.org http://www.costofwar.com http://www.facebook.com/nationalpriorities 413 584 9556 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Brute force attacks
I have an immediate interest in this discussion. One of my company's Django apps was recently subjected to an external risk assessment team audit. They found the fact that three invalid password attempts didn't lock out the user to be completely unacceptable. Granted, this is something that I should have applied myself, and if it were automatically part of Django it would frustrate many developers because it would inconvenience their users. However, considering it's an OWASP concern, and likely a wheel which will be reinvented repeatedly, I would like to see it in Django. I am willing to put my time into the effort. If Rohit and his team end up taking on the project I will coordinate with them to see how I can help. It seems that any implementation of this would require another value for settings.py, and I know that's something not done lightly. Also, the thread referred to above discusses throttling, whereas the "recommendation" provided to us by the auditors was user lockout requiring administrator activity (human intervention) to unlock. So the next question is whether the core dev team is interested in discussing configurable lockout (number of attempts and human intervention or timeout to release the lock), throttling, or both. Then, how to best go about it. Incidentally, I'll be at PyCon if anyone wants to get together after hours to work on this during the main days (I won't be at the sprints). Shawn -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Brute force attacks
Hi all, I wanted to revisit a key security discussion. Brute force attacks are the 7th most prevalent attack by number of incidents in the Web Hacking Incidents Database (http://projects.webappsec.org/w/ page/13246995/Web-Hacking-Incident-Database), which tracks publicly disclosed breaches in web application. This is ultimately because many applications do not have provisions to prevent brute-forcing. Django’s out of the box admin-site authentication is very awesome – so awesome, in fact, that inevitably people have and will continue to use it for more than just administrative users. Clearly Django takes authentication seriously. Can we revisit the idea of protecting against brute force authentication out of the box? (http:// groups.google.com/group/django-developers/browse_thread/thread/ 7559145e8c85d8c/b96c9a81e97f333b?lnk=gst&q=account +lockout#b96c9a81e97f333b). In particular, the idea of using throttling such as http://github.com/simonw/ratelimitcache/ or http://code.google.com/p/django-brutebuster/. Would you be willing to discuss further? My development team is willing to contribute whatever is needed to get this done if you think it's fruitful -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
