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 -~----------~----~----~----~------~----~------~--~---
