Locking users out of sites by exhausting a limited number of login attempts has always been a pet peeve of mine (not only because you can sometimes forget which particular password you used; but also because it becomes quite easy to perform a DoS attack against someone's account simply by locking them out via failed login attempts) that I thought most websites had done away with, not so Sudo Labs it seems. Now, I'm not about to take responsibility for this since it isn't our code base, and we didn't even think that it would be set up this way, but when I was talking to Kyran I found out that (much to our chagrin), he had gotten locked out.
Which got me thinking; why can't we have an over-ride code to allow people to login even when their account is being attacked. As I see it there's no reason we can't, we can even re-use existing code to achieve it.
These days when you want to sign up for most sites you get sent an email with an activation code/link which you have to use so that your account is activated, and we know you own the account.
Now, if we were to use the current lockout system, but give users an option to request a special login code, we would be able to leave the normal functionality working most of the time (except for when the user's account is being DoS-ed), but when they are being attacked they would not be locked out because they can easily just request a login code, and use it to bypass the lockout. Of course, this cannot be used by email vendors, who are already the crux of most of our identification, so its not much of an extra burden.
Subscribe to:
Post Comments (Atom)
2 comments:
We have been using a similar method on our sites. We lock out accounts after a number of failed login attempts and we lock out accounts if they have been inactive for a certain length of time. However, if the user uses the "forgot password" functionality (which entails sending a temporary tokenized link to the email account on record) and successfully changes their password, that will temporarily bypass both lockouts as we can take the completion of the process as an indicator that the actual account owner is requesting access.
This required very little additional coding on our part and no new process to learn on the part of the user. If the user has been locked out by their own multiple failures, then they most likely have forgotten their password. If the account was disabled due to inactivity, then even if the user has not forgotten the password, it is most likely time to change the password anyways.
Firstly, just a quick question; who is "we"? Your name doesn't ring any bells so I'm not quite sure what sites you are referring to.
But I'm glad you're doing this already, :)
The reason I recommended using something separate from the forgot password link is because (when blocks are not done per IP - in which case they can be somewhat circumvented via proxies anyway) people can be locked out by an attacker simply trying too brute force password - or specifically trying to lock the user out.
Of course, the user can at this point make a request to change their password, but it creates extra hassle for the user because they must then either remember (or write down) a new password, or go back and change their password to what it was before.
Admittedly that is only a minor inconvenience, but still one you would probably want to avoid.
Post a Comment