I think the simples solution coule be:
- add fixed 0.5 second delay to any login
- add two optional fields to db.auth_user that locks an account for 15
minutes after 3 failed logins.
Field('last_login')
Field('failed_logins')Massimo On Aug 4, 9:56 am, Jonathan Lundell <jlund...@pobox.com> wrote: > On Aug 4, 2009, at 6:01 AM, mdipierro wrote: > > > > > One issue is how to implement this.... if we use the > > request.env.remote_addr then it does not work behind a proxy, if we > > use request.env.http_x_if_forwarded_for, it works only on apache and > > it can spoofed anyway. > > I don't think we should be looking at the remote IP anyway. > > The problem is that these days a brute force attack can (fairly) > easily be distributed across a lot of zombie machines. > > If we just have a timer, and don't actually disable the account, then > the burden on the real user won't be that high, and then only if she > tries to log in while the attack is going on. > > A minor advantage to using only the account name is that all we need > to implement it is another field or two in the user table. > > > > > Ideas? > > > Massimo > > > On Aug 4, 7:50 am, Pynthon <forumx...@gmail.com> wrote: > >> Ah, nevermind then... > > >> On 4 aug, 14:47, mdipierro <mdipie...@cs.depaul.edu> wrote: > > >>> This can be added easily and it does not affect backward > >>> compatibility. > > >>> Massimo > > >>> On Aug 4, 7:37 am, Rob Scheibel <robschei...@gmail.com> wrote: > > >>>> Very good points in this discussion. I would like to see the > >>>> addition > >>>> of a processing delay added for numerous failed login attempts. > >>>> This > >>>> is what the larger sites are doing now - it slows down the > >>>> dictionary > >>>> attacks by adding 1/2 a second to each successive bad login attempt > >>>> until you hit some max (i.e. 20 seconds) and then it resets (note > >>>> that > >>>> it should be based on Host IP but also user account in case attacks > >>>> are coming from multiple IPs). Using this method it will take a > >>>> LONG > >>>> time to crack a relatively strong pass and most people give up > >>>> and go > >>>> elsewhere. It's also nice because it isn't too much of a nuicance > >>>> to a > >>>> user (they might be annoyed by a 20 second login delay, but they > >>>> can > >>>> still get in vs being locked out). > > >>>> It's also pretty easy to implement. You add a table to track the > >>>> "bad > >>>> IPs" and count/clear them based on timestamps. Then you add a > >>>> field to > >>>> the users table to track successive failed login attempts on that > >>>> account and clear it on each login. > > >>>> You could also always do like LiNode is doing and lock an account > >>>> by > >>>> resetting the pass to a random value after x bad logins and > >>>> emailing > >>>> the new pass to the user. > > >>>> just flat-out locking out users for a period of time can be used > >>>> to a > >>>> person's advantage. Say you knew "bob" had an account on a > >>>> system, but > >>>> you didn't want him to be able to access it. Then you'd just try a > >>>> bunch of bad passwords using his login and he'd be locked out... > > >>>> Just my $0.02. > > >>>> Thanks for the all the great work on web2py - it's been a treat to > >>>> work with! > > >>>> -rob > > >>>> On Aug 2, 6:57 pm, Jonathan Lundell <jlund...@pobox.com> wrote: > > >>>>> On Aug 2, 2009, at 3:10 PM, Jonathan Lundell wrote: > > >>>>>> On Aug 1, 2009, at 9:48 AM, mdipierro wrote: > > >>>>>>> Mind that none of this has anything to do with the ability of an > >>>>>>> attacker to guess the passwords to access a web2py site. This is > >>>>>>> about > >>>>>>> protecting the users form the administrators who may decrypt > >>>>>>> their > >>>>>>> hashed passords and access the users's account using their > >>>>>>> decrypted > >>>>>>> passwords (of an attacker who is already in the system and can > >>>>>>> act as > >>>>>>> the web2py administrator). But mind that the administrator > >>>>>>> does not > >>>>>>> even need to decrypt passwords to access them. He just log > >>>>>>> request.vars.password from the model file to get the login > >>>>>>> passwords > >>>>>>> before they are encrypted. This is true in web2py and in any > >>>>>>> other > >>>>>>> web > >>>>>>> based system. > > >>>>>>> I am much more concerned about a different issue: when an > >>>>>>> attacker > >>>>>>> wants to enter a site and repeatedly guesses the password. > >>>>>>> Perhaps there should be an option in auth that locks accounts > >>>>>>> after > >>>>>>> many failed logins. We could have another system table to handle > >>>>>>> that. > > >>>>>> How about a default STRONG as well as HMAC? If a developer > >>>>>> wants to > >>>>>> allow weaker passwords, let the burden be in that direction. > > >>>>>> An account-locking policy is a good idea. If the table has a > >>>>>> timestamp, the lock can be temporary, at least initially. Lock > >>>>>> the > >>>>>> account for a n seconds after n failures. Or something like that. > > >>>>> One reason for a delay that simply imposes rate-limiting is that > >>>>> permanent (or semi-permanent) locking makes for an easy DOS > >>>>> attack. > > >>>>> As for a system table, wouldn't auth_user be the logical place > >>>>> to put > >>>>> the necessary fields? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
