I manage a web application, which is accessed behind a login system and I’m now asked to implement some additional security features. One of the ideas is to limit the frequency of failed logins, for example after 10 unsuccessful attempts the user has to wait 10 minutes in order to be able to try again. But this has one flaw - anyone can take someone else’s user name and lock them out of access by using the login form and deliberately exceeding the attempts limit. This could be done even by a bot.
Therefore, I’m wondering if there is an idea, something that would mitigate this flaw. I like the idea of limiting login attempts but I don’t want to cause trouble to legitimate users, who could be prevented from entering the system by any malicious user who knows or has guessed their user name.
Keeping usernames private is also normally done, which would keep random people or bots from knowing a username to use for that password attempt. Make sure your system is never giving out a username, or telling someone that a failed login is due to an illegal username. It’s just a “username/password is wrong” message. Then if you still get the multiple password failures, you might send an email to the person to tell him about it and provide a way to correct it out of band from the regular login page or report it as “I didn’t do that”.
I would definitely implement what you’re saying though, probably not with 10 tries, maybe more like 3.
I’m afraid this would be impossible since the user names are not hidden from other users and they are visible in various parts of the system. Moreover, they are often short and easy to guess.
The idea of sending an email seems good, this would alert the user of any suspicious activity.
To my mind 3 is definitely too few. I was frustrated many times by systems implementing 3 attempts while I was a genuine user trying to remember my password but I just needed a few more tries than 3.
As I think about it there’s no bullet proof way of avoiding the ability to temporarily lock out other user’s accounts with such a system but I also think it’s better to implement it than not. I might monitor the situation and if such cases happen then I’d try to come up with a solution. But maybe things like that will not happen at all or be so rare that it’s not worth worrying about.
That’s generally called a security flaw if usernames are easy to guess. Making an attack figure out both a username and a password is part of the strength of that implementation.
Hm, I might be then missing something big here because I never considered making user names hard to guess a security measure, especially that many forums use the same user names for display (next to each post) and to log in. And one of the most popular user names ‘admin’ or ‘administrator’ is most easy to guess. Anyway, user names in this system are known to other users and I have to live with that. Maybe in the future we will switch to displaying real names or company names instead of user names but this is not on the agenda now.
I guess it depends upon criteria you use to identify “a number of attempts”.
It sounds like you are counting attemps on a particular user account, regardless of the source.
You could maybe count attempts from the same source IP.
Having said that, I do reacall I site I managed which was suffering brute force attpemts to the admin back-office, and every attempt had a new IP, to evade an IP block.
Another thought, is there a time scale for the 10 attempts?
Bots usually work fast and may make 10 attempts in as many seconds (or even less). A fumbling human who is struggling to recall their password will be considerabley slower.
Perhaps enforce a lock if there are 10 attempts within x seconds, and also reset the count to 0 after y amount of time since the last attempt.
I just say x and y as you may need to think about or experiment with optimal time scales for this.
Sure, but the real problem I have is not how to tune the times and count limits but the fact that with such a system any stranger can lock out other users by misusing the login form with their user names. That’s what I need a solution for.
So far, a good solution provided here might be sending alert emails to the user with a link to bypass the lock - I’m just trying to think if this will not decrease security in some way by trusting that the email will reach the right person but probably I’m going too far with my suspicions. After all, I need to trust something and email addresses need to be trusted in such a system, anyway.
How about, once the user has attempted three times, ask for an extra piece of information that isn’t normally available to anyone other than the user, to rule out the idea that it might be someone else? If email addresses aren’t normally available to other users, you could ask for that in addition to username and password, or even add a field in the user profile specifically for the purpose. Then continue to whatever number makes you feel comfortable before locking the user. It doesn’t entirely remove the problem, but it reduces the chance that you’ll get to ten attempts by someone / something just trying to cause trouble.
This seems like another good idea. I just don’t know what kind of information I might require in my case without causing too much trouble for users. I think this would fit better in an application where users provide some personal information that they can always provide without having to additionally store or remember, like birthday, personal ID number, phone number, etc. In my case many accounts are managed by companies and the only personal information can be name and surname, email addresses may not be unique across accounts. So for now I think I’ll go for sending emails in case login attempts are exceeded.
Another solution is to drop a cookie on the users device every time they log in containing the hash of their username (hashed together with some secret salt). Then, when someone has 10 failed logins in a row for a username block that username from logging in except on those machines that have a valid cookie (ie the hash matches their username plus the same salt).
Basically logging in correctly once makes the application trust that device and therefore assume they’re not bad actors.
Of course, if someone logs in for the first time on a new device while their account was just blocked it won’t help, but that probably won’t happen much, since people tend to stick to a few devices.