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