undefined | Better HN

0 pointsHizonner1mo ago0 comments

How do you "determine" individual clients to show them CAPTCHAs? Yes, you can, and probably should, make some use of IP addresses, although that would work better if idiots hadn't polluted the Internet with quite so much NAT.

But you don't have to, and you definitely don't have to completely rely on it. Look for a cookie. If you don't see it, route the client through a page that sets it.

Yes, this is subject to flooding attacks... in exactly the same way that every CAPTCHA system is subject to flooding attacks. But it actually uses fewer resources per request than showing the CAPTCHA would.

0 comments

2 comments · 1 top-level

IshKebab1mo ago· 1 in thread

> How do you "determine" individual clients to show them CAPTCHAs?

Cookies.

> Yes, this is subject to flooding attacks

Err... Yeah exactly.

> in exactly the same way that every CAPTCHA system is subject to flooding attacks.

Uhm no the whole point of captchas is that it requires (or used to anyway) humans to solve them, thus limiting the rate to human speeds.

HizonnerOP1mo ago

> Uhm no the whole point of captchas is that it requires (or used to anyway) humans to solve them, thus limiting the rate to human speeds.

The CAPTCHA challenge page itself has to be served to a client that has not yet given any evidence that it's not a bot. It's just as expensive to serve the challenge page as it is to serve a cookie-setting page. Bots can infinitely retrieve the challenge page (and can also infinitely try to retrieve the underlying "authenticated" page, forcing you to process redirects).

The only reason it looks better to you is that a third party is serving the CAPTCHA. You could also have a third party serve the cookie-setting page.

j / k navigate · click thread line to collapse