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