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.