Live, deliberately transparent demonstration
One expensive minute for the browser.
One cheap hash for the server.
During unusual failed-login traffic, this small Hashcash-style gate can run before an expensive password verifier. It is friction, not authentication or a CAPTCHA.
Consent before computation
The demonstration uses one browser worker to search for a SHA-256 result with server-selected leading zero bits. It may use noticeable CPU and battery. Nothing starts until you choose a mode.
No password is requested or sent. Challenges expire, are bound to this network prefix and demo purpose, and can be accepted only once.
Browser SHA-256 search
Requesting a signed challenge…
Hashcash completion is probabilistic. The bar shows the chance that a solution would normally have appeared after this much work; it reaches 100% only on success.
Server accepted the proof
Verification cost stayed tiny.
What this does—and does not do
- IP and network-prefix limits plus a global password-work semaphore protect server CPU first.
- The puzzle appears only under unusual load or a local rate threshold.
- A signed random challenge prevents precomputation; expiry and one-use consumption prevent replay.
- The worker never receives the password.
- Botnets and fast GPUs can solve SHA-256 much faster, while slow devices may take longer. Proof-of-work does not replace ordinary throttling.
Read the complete, dependency-free source and security writeup on GitHub · Back to Flypaper