It's imperative that we protect credentials with great care, such as properly hashing the low entropy secrets with algorithms like Argon2 or Scrypt...
For further actions, you may consider blocking this person and/or reporting abuse
CAPTCHA would be the sort of thing you'd put in an abusable, expensive endpoint (eg session token creation or full text search), or else to prevent automatons creating loads of single-use accounts. You can deal with it on the client or the server, but if it isn't matching, you kill it off ASAP.
It's there to reduce bot activity in things that could be expensive, not to be a bar of entry for a returning user who may have already invested in your product.
Discord is an example of using CAPTCHAs during sign in process. So is Riot.
Password hashing functions are expensive operations. Which you must take the password input, hash it, then compare it with the stored hash.
That falls under session token creation though.
I mean bar of entry as requirement after first failure, usually by IP and ID. It might be expensive, but with a use-after-fail it might make more sense.
I say this knowing that I'm simultaneously recommending two practises that are non-similar... it made a lot more sense in my head, anyway.
The tl;dr is that only put it in if you have some need not to, keep tokens that allow bypassing any other requirements or so on.
Ah, okay. That makes more sense.
CAPTCHAs aren’t for security, they’re for preventing bots from for example creating a ton of accounts or spamming a contact form.
Actually, CAPTCHAs are also used for sign in processes in some services. Discord for example takes this approach. And it provides security ... KIND OF.
If you have a script/bot hammering sign in page, you could protect it with CAPTCHAs. The whole point of CAPTCHAs is to prevent bots/scripts.
I never said anything about sign in processes.