2

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?

|improve this question
5

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.

OWASP have more details on preventing this kind of attack.

|improve this answer
  • 3
    Option B.1: Instead of locking the account after X number of failed login attempts, implement a delay. After X number of failed login attempts, the account is locked for 1 minute. Then, with the next fail, 2 minutes. Keep increasing it (up to a reasonable maximum) and you make brute force attacks like this infeasible without making them too much of a burden on the legitimate user. – Mason Wheeler Jul 28 '13 at 14:27
  • 2
    I find Option B being as bad as not being able to process all the requests. If you can lock user's account after X attempts (even if it's for a short period of time), you can pretty much shut off most users from using the website. Option C, however, seems like a better all-around solution. – Pijusn Jul 28 '13 at 14:52
  • Option B introduces a very real DOS attack vector to the site while trying to mitigate an imagined CPU overloading attack. – recursion.ninja Oct 13 '13 at 20:35
3

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.

|improve this answer
  • "Hashing is actually very 'cheap' compared to the time to execute the database lookup to confirm it." That's blatantly not true - if it is you're doing something very very wrong. – orlp Jul 28 '13 at 15:49
  • The numbers I've run say different, but it would depend on what algorithm and settings you're using. – James Snell Jul 28 '13 at 16:03
  • How much time does such a database lookup take in the setting you've measured? – orlp Jul 28 '13 at 16:36
  • I can't give away the details, sorry, not that I have them as I'm on other projects now. You'll have to run your own benchmarks. – James Snell Jul 28 '13 at 19:02
0

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.

|improve this answer
  • Performing the hash should be slow, so that reversing the hash is slow even if the attacker drastically shrinks the search space, for example by performing a dictionary attack rather than brute force collision search. Note that "slow" here means "slow for a single operation, compared to fast hash functions", i.e. taking something between a microsecond and a second to hash one password, not "infeasible" like trying 2^128 or more inputs. – user7043 Jul 28 '13 at 12:38
  • Actually, the OP is talking about hashing methods that are intentionally made slow. For example, take a look at bcrypt: en.wikipedia.org/wiki/Bcrypt – Radu Murzea Jul 28 '13 at 12:39
  • In the case of using a very slow hash generator then it might be better to use a faster hash algorithm when under heavy load and then only process the hits through the slower one later. – James Snell Jul 28 '13 at 13:36
  • @JamesSnell, you don't get to choose faster or slower algorithms depending on the load. You must use same algorithm for generating the hash and checking password validity (or whatever you are hashing). If you meant slower/faster algorithm implementations, then I see no reason to use the slower one at any moment. – Pijusn Jul 28 '13 at 14:46
  • @Pius - You can, you just need to store the results of both hash algorithms is all. For example if you do MD5 and bcrypt. Under heavy load / attack conditions you use the cheap algo to reject early and if it passes you'd still need to do bcrypt. Under normal load you just do the bcrypt. – James Snell Jul 28 '13 at 15:43
0

Track IP addresses and check login attempts per minute not allowing further attempts for awhile beyond some threshold.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.