On Aug 4, 2009, at 2:06 PM, mdipierro wrote:

>
> I think the simples solution coule be:
> - add fixed 0.5 second delay to any login

I like that.

> - add two optional fields to db.auth_user that locks an account for 15
> minutes after 3 failed logins.
> Field('last_login')
> Field('failed_logins')

How about just making the delay: 0.5 + max(failed_logins, 10) seconds?

A brute-force attack is going to require many, many attempts, so is  
there really a need to lock the account for more than a few seconds? A  
10-second delay will throttle the attack to 360/hour per attacking  
machine, which will make a brute-force attack impractical unless the  
attacker is incredibly lucky, or the victim has an incredibly bad  
password.

An it won't be necessary to give any feedback to the user (though we  
could do a flash, I suppose), since worst case it'll just be a rather  
slow (10-second or whatever) response to the login attempt.

It'd be useful to log something for the admin if failed_logins exceeds  
some threshold.


>
> Massimo
>
> On Aug 4, 9:56 am, Jonathan Lundell <jlund...@pobox.com> wrote:
>> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to