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