Re: throttling login attempts to avoid brute force attacks

On Jul 8, 11:03 am, Shawn Milochik wrote: > This topic came up on the list a few months back, and I just wanted to > share the solution I've put into place. > > Short version: > > 1. Ensure that my Web server (nginx) passes the user's real IP address > in the request. > > 2.

Re: throttling login attempts to avoid brute force attacks

Like with any brute force protection, it depends how paranoid you want it to be. You'd generate a hash of specific request parameters (such as session id, user agent, etc etc). All you'd need to do is add a new field next to ip called requesthash, then use unique_together on those two fields On 9

Re: throttling login attempts to avoid brute force attacks

On Fri, 2011-07-08 at 12:03 -0400, Shawn Milochik wrote: > I'm using IP instead of user because this prevents an attacker > from > inconveniencing a legit user or getting a "fresh start" just by > guessing > a different username. > > and what happens when you have a 100 users from the

Re: throttling login attempts to avoid brute force attacks

On 07/08/2011 12:53 PM, Jacob Kaplan-Moss wrote: Hi folks -- Also see http://simonwillison.net/2009/Jan/7/ratelimitcache/ for a discussion of a similar technique built on top of memcached. Jacob Thanks for that link. There's some really good stuff in the comments. I'm seriously considering

Re: throttling login attempts to avoid brute force attacks

Interesting approach. Although, I don't like the "get multi" approach, too much overhead. I personally prefer to configure an amount of time, combined with the max hits, then do the following: class IPThrottleException(exception): pass import time MAX_INTERVAL = 180 #

Re: throttling login attempts to avoid brute force attacks

Hi folks -- Also see http://simonwillison.net/2009/Jan/7/ratelimitcache/ for a discussion of a similar technique built on top of memcached. Jacob -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to

Re: throttling login attempts to avoid brute force attacks

On Fri, Jul 8, 2011 at 5:37 PM, Shawn Milochik wrote: > On Fri, Jul 8, 2011 at 12:32 PM, Cal Leeming [Simplicity Media Ltd] > wrote: > > > > > > Have you considered using an atomic caching server for storing the state > of > > an IPs

Re: throttling login attempts to avoid brute force attacks

On Fri, Jul 8, 2011 at 12:32 PM, Cal Leeming [Simplicity Media Ltd] wrote: > > > Have you considered using an atomic caching server for storing the state of > an IPs 'throttle' count? > It has the added benefit of giving you future support for distributed

Re: throttling login attempts to avoid brute force attacks

On Fri, Jul 8, 2011 at 5:32 PM, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> wrote: > > > On Fri, Jul 8, 2011 at 5:03 PM, Shawn Milochik wrote: > >> This topic came up on the list a few months back, and I just wanted to >> share the solution I've

Re: throttling login attempts to avoid brute force attacks

On Fri, Jul 8, 2011 at 5:03 PM, Shawn Milochik wrote: > This topic came up on the list a few months back, and I just wanted to > share the solution I've put into place. > > Short version: > > 1. Ensure that my Web server (nginx) passes the user's real IP address in > the

Re: throttling login attempts to avoid brute force attacks

I'm not familiar with shm, so I can't answer that. I don't share the in-memory db with anything else; we have a very small user-base for our commercial application, and only need one Django instance. If I wanted to trigger other activity based on this I'd probably use ZeroMQ. Sorry I can't be

Re: throttling login attempts to avoid brute force attacks

On Fri, Jul 8, 2011 at 5:03 PM, Shawn Milochik wrote: >    Middleware file creates an in-memory sqlite3 database. How do you share this in memory db with the other processes? Can one create sqlite databases that use shm? Intrigued. Cheers Tom -- You received this message

throttling login attempts to avoid brute force attacks

This topic came up on the list a few months back, and I just wanted to share the solution I've put into place. Short version: 1. Ensure that my Web server (nginx) passes the user's real IP address in the request. 2. For POST requests to the login URL only (to avoid any performance