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