Temporarily save failed logins password hashes for using against brute force attack

Question

My question is about online brute force attacks, that try to authenticate in the website.

1) For the first case if the requests are coming from the same ip, I think this are relatively easy as after some failed attempts we can block the ip for some time or show a captcha, or increase the delay between login attempts etc.

2) second case, lets consider the attacker is using proxy, making requests from different ip addresses, but targeting a specific account, not sure what is the best practice here, but maybe showing captcha only for this account if there were many failed attempts from different ips, or maybe considering the user's whitelisted ips. Also warning somehow the account owner as well, that were failed logins https://www.owasp.org/index.php/Guide_to_Authentication#Architectural_Goals

3) Anyway, I think the above 2 attacks are more or less possible to find out. But for the third case if the attacker is using multiple ips(lets say thousands or more) targeting different accounts, but using the same password, as there is a higher possibility that at least one user would have that password. In this case if the attacker is making a few requests per IP during a reasonable time, perhaps he could check thousands of accounts for that chosen password without being noticed/blocked.

Now, what are the pros an cons of temporarily, lets say at the level of hours or days, save(in the database) the password hashes of failed login attempts(with a single application - side salt), and if the password was requested a lot during the last x hours/days require a captcha or some other kind of defense, before even checking the password.

Also, lets consider that password policies are applied during registration, for example, min 6 or 8 characters long passwords, disallowing the usage of well known passwords. Also, for usual password hashing im using unique salt per user(and using either blowfish or sha512), but want to use single salt for failed passwords and sha 256 or 384 to be faster.

thanks

Answer 1

The answer will completely depend on how you define your threat model and what your risk appetite allows.

Since you already went so far as to identify the potential attacks in a fair amount of detail I'd assume that you believe these are credible and possible threats that you face. If it is not the case then there should be no reason to try and protect against a them.

Pros

• As you correctly point out, temporarily storing the hashes of failed password attempts could potentially give you the necessary data to more effectively detect an attack as described in scenario 3. If this process can then require a captcha prompt or some second factor of authentication you will most certainly hinder the attempts of the attacker enough to make the attack impractical.
• You could potentially learn a lot about the nature of these attacks from the data gathered, like the type of passwords the the attackers attempt and how they cycle through them (simple brute force vs. dictionary attacks). This however is more an academic gain than it is directly related to the security of your system, although you could identify long term trends that could result in better identification techniques in future.

Cons

• The main consideration you will have to make here is if the tradeoff of increased security vs. extra resources and processing required is worth your while. This is due to the fact that comparisons you intend to make can be very computationally expensive and could require a significant amount of extra resources (depending of the size of the system and the amount of log in attempts you expect to receive).
• I suspect the comparison you intend to make in order to identify these attacks outlined in scenario 3 in not as straight forward and simple as it seems at first. Firstly, as stated before, you might need some more resources in order to store and compare the hashes of passwords. In your description of scenario 3 you assume that the request coming from various IP's will all attempt the same password across as may accounts as possible at a time. This will mean that you won't be able to process each log in request in its own right but rather that you will have to evaluate the the log in attempts as a batch to be able to see that there are multiple log in attempts on various accounts using the same exact password. Remember that a legitimate user might be attempting to log in coinciding with the attack and that the whole batch of log in attempts will have to be queried if fowl play is suspected. This could lead to a degraded experience form the user perspective if it happens often. It will also be difficult in determining how long a specific hash will need to be stored after it was flagged as an artifact of a specific suspected attack. You cannot keep the hash in there indefinitely since it could be the hash of a legitimate user's password that will then continually be queried and this could lead to you in essence "DDoS'ing" your own system. If you do decide to implement a system like this only trail and error over time will be able to indicate how it should be configured in order to work effectively without being too much of a burden.

If your aim is to protect your users and their data on your system rather than specifically identifying these attacks, I'd suggest you look at rather implementing (possibly even requiring) a multi-factor authentication mechanism. Educating your users as to the threats you face and the benefits of using multi-factor authentication to protect them could be a much better approach to securing the system with much less friction and effort from your side.

Answer 2

I don't see the point in worrying about your scenario #3; that tactic will be just as successful as scenario #4:

4. A botnet targeting many accounts trying one of many common passwords on each attempt.

Imagine you have a million users, 10% of which randomly use one of the 1000 most common passwords (123456, password, letmein, ...). If a botnet tries attacking all million accounts with the first password on the list and then tries the second password on the list, down the line, every attempted login will have a 1 in 10000 chance of working. If the botnet randomly chooses a password for each account it attacks, it will have the same success rate. The only complication is originally if the botnet wanted to prevent repeated work it had to go through the list of logged in accounts in some sort of order (or keep track of accounts already tried). Now it just just has to go through the list of (login, password) pairs in some sort of order (or keep track of ones tried) to prevent wasted attempts.

Granted, there are things you can do to prevent against scenario 3 & 4.

1. Don't let users use common passwords. Get a large database of leaked passwords and whenever a user sets up or changes a password, make sure it isn't on this common list. Having password complexity rules also helps (e.g., one capital, one number, one symbol) that prevent many common passwords (123456, password or letmein) -- granted your rules should be flexible to allow long passphrases like correct horse battery staple.

2. Keep track of IP addresses associated with accounts. If account johndoe has never successfully logged in from 1.2.3.4 before, require CAPTCHAs or 2-factor authentication (receive a code via SMS/phone call/email) before they can login from that IP.