Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
These days password hashing algorithms are designed to be slow. While it prevents black hats from guessing the password (at least partially), it also gives additional work for the server.
I can imagine that, if someone wanted to make server run extremely slowly, they could simply send many log-in requests which would lead to many password hash calculations therefore dramatically increasing CPU usage.
What is the common practice for preventing such attacks? And how is it called?
Your best method for protecting against this kind of attack is to implement some kind of limit to the number of times logins can be attempted before the account is locked.
You can do this in a number of ways, that have their advantages and disadvantages. Like everything in security, you have to balance the pros and cons.
Some possible solutions:
Option A: Limit number of login attempts from an IP address. However, IP addresses are easily spoofed and some bruteforcing tools may switch IPs between each attempt.
Option B: Lock the account after X number of failed login attempts. However, you would then need a way for a legitimate user to unlock their account.
Option C: Use a captcha. This might be annoying for legitimate users, but it will make it difficult for an automated system to attempt many logins.
It is called a 'resource starvation' attack, that applies to any situation where the work on the part of the attacked party is greater than the work required by the attacker.
Hashing is actually very 'cheap' compared to the time to execute the database lookup to confirm it.
There are a few mitigations you can apply. In the event of an attack you first off want to increase the 'cost' to the would-be attacker. CAPTCHA's can help with this, but they have a negative impact on accessibility generally. So the best option is to have them 'turned off' and then enable them based on a server side trigger.
You can limit requests but it's easy to get around. You can globally delay and limit the processing of each login request so each IP can only issue one login request at a time and has to wait before the server even begins to process it. If they issue another request before the request is completed then you can dump it cheaply. But this has the downside that it is more complex to implement and that it could affect clients behind a NAT router. Everyone else would be happy to wait a couple of seconds with a 'please wait' type dialogue - again it ramps up the cost for the attacker as they require more sources to attack from.
If your system can make you aware of an attack in real time then you can work with your hosts to block or limit problem traffic (for example from regions you don't supply or serve) so the attackers essentially saturate their own routes into your servers or direct the attackers into various sinkholes and honeypots.
Ultimately it comes down to being just like any other distributed denial of service attack in that it's a case of managing load. Ultimately if it's a cloud based system you might want to just spin up more capacity (although you need to be aware of the costs involved).
Ultimately the answer is to go read up on security to understand the whole landscape. Have a look at Security.SE:If you could only have one book on web security, what would it be? for suggestions.
Performing the hash isn't necessarily slow. It's reversing the hash that's painfully slow. (This is only needed if you have the hash and need to calculate the original password - something that your log in functions don't need to do).
The attack would be called a Denial of Service (DoS). The common defense is to start ignoring the IP address of the attacker after too many failed log in attempts.
Track IP addresses and check login attempts per minute not allowing further attempts for awhile beyond some threshold.
