> 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
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
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
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 defa
(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
ck.
-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/0b44e048b5b
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
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-pH
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
+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 Sec
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
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 config
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 brut
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
nough 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 prev
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
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
h-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 accepta
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 u
onveniencing 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
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 I
n 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
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-Hack
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
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 vulnera
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 a
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 shou
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
28 matches
Mail list logo