Xtykutl

Imagine a campaign where a visitor with a unique win-code from a product package can win immediately by entering just the code. The client wants email etc. after validating the winning code. This is uncommon, but much more sympathetic as opposed to demanding email and personal data before checking if one has won i.m.h.o.

So, the flow for the visitor would be:

[ ENTER CODE ]

  !win -> [ TOO BAD ]

   win -> [ CONGRATULATIONS ] -> [ ENTER PERSONAL DATA ]

This scenario would mean a brute force bot could try codes until the response would differ, implying a winning code. Would you use/build a (re)captcha?

How would you protect from flooding? An attacker could easily spoof IP / UserAgent for every request.

Is it even possible to protect such a mechanism in this flow?

General question, general answer...

Better to make the code long enough that this becomes infeasible.

Consider the threat model: why would someone go to the effort of doing this? Are the payouts that high?

There's no point in an attacker spoofing IPs as they would never see the responses, and they can't spoof IP with TLS & HTTP anyway (they can hide behind a proxy, but that's not spoofing). So long as the number of proxies/IPs is much smaller than the number of possible codes, you shouldn't have a problem limiting by IP.

You could make requests expensive - use a challenge-response system to make clients do a huge number of hash iterations to rate-limit requests (see hashcash). If it takes 1 second, that limits the potential request rate significantly, but doesn't penalise real users excessively.