Well, I don't understand the whole topic but if it is insecure then security goes forward backward compatible IMO.
On 4 aug, 14:37, 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 -~----------~----~----~----~------~----~------~--~---
