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.