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