How proof-of-work verification works

The purpose of a verification screen is not to tell a human from a bot — doing that reliably is hard. The purpose is more modest and more effective: make the visitor pay the cost of running a real browser engine.

A flood tool can send thousands of requests a second because each one costs it almost nothing. Verification breaks that balance.

The challenge

The server issues a problem that takes compute to solve. The classic form: "append a number to this text such that the first N bits of its SHA-256 digest are zero."

token     = time : subnet : browser_signature : difficulty
signature = HMAC-SHA256(secret_key, token)
page      = token + signature + difficulty

The browser finds the number by trial and error. A difficulty of 14 bits takes a few hundred milliseconds on a typical device — the visitor does not notice. For a bot wanting 10,000 requests a second, that same cost takes the attack out of the realm of the economical.

The difficulty race: a quiet bug

There is a mistake in this design that is easy to miss. What happens if the verifying side recomputes the difficulty?

A visitor receives the page and honestly starts solving a 10-bit challenge. Meanwhile the site owner changes the setting in the panel. When the visitor submits the solution the server now expects 14 bits and rejects the honest answer. The user sees 403 insufficient proof of work.

That is a violation of rule number one. The fix is simple but important: the difficulty travels inside the token and is signed. Verification expects exactly what the page was told. Whether the setting changes or the vhost record is purged, the visitor's solution stays valid.

What the clearance cookie is bound to

The cookie issued after a solved challenge is bound to three things:

• Time: it has a lifetime and carries a small tolerance for clock skew.
• Subnet: /24 for IPv4, /64 for IPv6. A stolen cookie is useless on another network. Binding to the full IP would re-challenge mobile users on every cell handover.
• Browser signature: a hash of the User-Agent. A cookie copied into a different client is invalid.

The cookie itself is HMAC-signed and checked with a constant-time comparison. Its contents cannot be forged or modified.

About the checkbox

In the panel you can pick "checkbox" instead of "automatic". Let's be honest here: the checkbox itself is not a security control. What the server verifies is the same proof-of-work in both modes. The box only provides a familiar interface and a "a real interaction happened" signal.

So the choice between the two modes is not a security trade-off but an experience preference. Picking the captcha does not weaken protection, and picking automatic does not leave you weaker either.