0

I was reading this post from half a decade ago about the pros and cons of using captcha during a DDoS attack (How does CAPTCHA mitigate DDoS attacks?)

At that time there seems to be basically 2 opinions:

1) Captcha is good when DDoS is happening because it only requires a check for the captcha itself, no password hash and database hit if captcha fails.

2) Captcha is bad during DDoS because it requires processing to check the captcha making the request take up even more processing.

Today reCaptcha is everywhere. Most of us do not generate and check captchas on the server side, but just make a POST call to google to verify if the posted captcha is valid, how does this compare to hashing the pass and hitting the database in terms of processing time?

The POST request seems to takes longer, but the auth verification takes more processing time. How does this impact the server during a period of a DDoS attack?

sigmaxf
  • 623
  • 7
  • 17
  • It does help somewhat but there are already many break systems for it. One of them was showcased in Blackhat asia 2016: https://www.blackhat.com/docs/asia-16/materials/asia-16-Sivakorn-Im-Not-a-Human-Breaking-the-Google-reCAPTCHA-wp.pdf Only use of recaptcha does not help. You need to use multiple solutions to mitigate DDoS. – tech_enthusiast Apr 09 '18 at 02:12
  • I think performance hit because of point 2 is irrelevant. You can store captcha result in the session variable, validating it is very fast and no hash calculation nor database access is needed. – ThoriumBR Apr 09 '18 at 13:22

4 Answers4

4

I'm not sure about this one.

Captcha helps against brute-force attacks, e.g. someone logging onto your forum to upvote their favorite anime character on a survey, but Captchas don't help against a network level attack, where an attacker with a botnet is just flooding your server with http/tcp requests, causing it to fall over.

In short, a network level DDOS isn't mitigated by captchas. But they can be used for when you want to limit bot-interaction to your APIs or website, to ensure only humans are accessing it. This limits the traffic pumped through your servers, and generally help with the volume.

keithRozario
  • 3,571
  • 2
  • 12
  • 24
1

The most voted answer to the question you've referred to doesn't stick to either of the opinions you've outlined, and it's still valid:

  • Today, not all automated activity is malicious, and not all humans are completely innocent.

  • Users usually hate CAPTCHAs.

  • OCR research is always ahead of CAPTCHA research. Actually, today, a CAPTCHA engine is only secure as long as its source code stays private, which, for the information security field, is probably something quite unusual.

Also:

  • OCR research is one thing, but voice recognition is developing even faster. Either you make your CAPTCHA available as a voice message and thus weaken it even more, or you're leaving people with disabilities behind which doesn't seem appropriate in most of the use cases.

  • As @keithRozario has pointed out already, the DDoS isn't in any way limited to application layer attacks. Any CAPTCHA won't help you against network layer attacks, or transport layer, or attacks targeting TLS encryption (which your CAPTCHA-offering Web site probably operates on top of).

Personally, I would also doubt using a free Web service for anything commercial, because with reCAPTCHA, you're essentially making Google pay for your requests, and there ain't no such thing as a free lunch. But maybe that's just me.

ximaera
  • 3,395
  • 8
  • 23
1

Not in an of itself but it can be a tool to stop DDoS/DoS attacks. It's mostly only useful in stopping layer 7 attacks (attacks against applications like web servers). It's useful because it can make an attack harder for an attacker or infeasible. If an attacker has to make hundreds of thousands of requests per second and they're requesting some resource intensive part of a site like a search function then it makes sense to verify that everyone making a search is in fact human. In such a case, Recaptcha is better than running your own captcha because generating a captcha takes some effort on your servers end and thus could just become another (albeit less effective) target to attack, Recaptcha lets google do all the work. Also, Recaptcha is a really good captcha because it has challenges that are actually hard for computers to solve. Most captchas use text which since the introduction of Convolutional Neural Networks (CNNs) are trivial to break. In terms of which is better, a POST to google or checking a password. I'd say that in most cases you'd be better off with the POST because google can handle a lot more open connections than your database probably can so you're far less likely to hit a bottleneck. Also, if you have too many connections to your DB nobody can login or use anything that uses that database, if you have too many connections to google new people can't login and you might have some network issues but already logged in users should still be able to use the site (depending on how you rate limit things).

Nick Mckenna
  • 507
  • 2
  • 8
1

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.

Enos D'Andrea
  • 1,047
  • 5
  • 12