2 Removed use case for users already logged on because it was not pertinent to the question.
source | link

Some of the other answers seem to miss the specificity of this question.

If you are not referring to a login POST, you do not need neither hasing nor CAPTCHAs. You just need a DB read to check for an existing session token.

If you are referring to a login POST, theThe preferred solution depends on your resources (CPUs, bandwidth, latency) and on the number of hashing iterations used. Also consider that an external CAPTCHA services may intentionally blacklist your IP (some central authentication providers do it toor throttle servers which verifygenerate too many failed logons - been there, got the t-shirt)much traffic.

Lastly, I second ximaera's answer in that if you care about DDoS then your business most probably does not want to hand over its liston the dangers of clients to a free web service (which will then sell themservices and other answers on the need to your competitors)implement network DDoS defences.

Some of the other answers seem to miss the specificity of this question.

If you are not referring to a login POST, you do not need neither hasing nor CAPTCHAs. You just need a DB read to check for an existing session token.

If you are referring to a login POST, the preferred solution depends on your resources (CPUs, bandwidth, latency) and on the number of hashing iterations used. Also consider that an external CAPTCHA may intentionally blacklist your IP (some central authentication providers do it to servers which verify too many failed logons - been there, got the t-shirt).

Lastly, I second ximaera's answer in that if you care about DDoS then your business most probably does not want to hand over its list of clients to a free web service (which will then sell them to your competitors).

The preferred solution depends on your resources (CPUs, bandwidth, latency) and on the number of hashing iterations used. Also consider that external CAPTCHA services may intentionally blacklist or throttle servers which generate too much traffic.

I second ximaera's answer on the dangers of free services and other answers on the need to implement network DDoS defences.

1
source | link

Some of the other answers seem to miss the specificity of this question.

If you are not referring to a login POST, you do not need neither hasing nor CAPTCHAs. You just need a DB read to check for an existing session token.

If you are referring to a login POST, the preferred solution depends on your resources (CPUs, bandwidth, latency) and on the number of hashing iterations used. Also consider that an external CAPTCHA may intentionally blacklist your IP (some central authentication providers do it to servers which verify too many failed logons - been there, got the t-shirt).

Lastly, I second ximaera's answer in that if you care about DDoS then your business most probably does not want to hand over its list of clients to a free web service (which will then sell them to your competitors).