PrivCaptcha.com

Account takeover protection for logins and password resets

Someone targeting one specific account, working password reset, resend-code and contact-change routes rather than the login box.

How an account takeover attempt works

The attacker POSTs forgot-password repeatedly, then works resend-code until the victim approves. Paced like a person through a residential proxy: two hundred pushes at one account in ten minutes.

What account takeover looks like in your logs
Password resets dozens of times on a few addresses, site total flat.
One account, a burst of push prompts, no successful login.
Reset and contact-change POSTs with no matching page view.

How PrivCaptcha stops account takeover

Four steps, with the numbers the server uses. Nothing here is configured by you.

Resend and change, not just login

Widget on the reset-request form, the resend-code control, the contact-change forms. List your domains and a phishing copy of your reset page is refused.

One token authorises one send

A challenge mints one token, the verify before the send spends it. Two hundred pushes means two hundred challenges.

Score climbs on failure, not volume

Real browsers start at 20, level 2. Failures add +8, capped +40. Five wrong reach 60: level 4 on the visual path, 10 degrees, 6 pixels.

Verify before the message goes out

The verify sits ahead of the side effect: before the reset mail is queued, the code sent.

What a account takeover run costs now: Each send needs its own SHA-256 search: 2^14 hashes for a clean client, 2^17 after five failures, 2^19 for a script at 85. Charged per send, two hundred times.

Add PrivCaptcha to your password reset form in two lines of code

Script tag, container in front of the submit button, and your existing verify call. Already on reCAPTCHA or hCaptcha? That backend code stays exactly as it is.

reCAPTCHA siteverify hCaptcha siteverify
Server SDKs
<!-- password reset form -->
<script src="https://privcaptcha.com/1/api.js" async defer></script>
<div class="privcaptcha" data-sitekey="your-site-key"></div>
<!-- server side, unchanged -->
POST https://privcaptcha.com/api/v1/siteverify
Where it goes

The reset form, the resend controls, the email, phone and 2FA-change forms.

What the backend does

Call siteverify before the side effect fires. A missing or redeemed token must fail.

The usual mistake

Verifying once per recovery flow and letting resends ride on it. Tokens are single-use. Fresh widget per send.

What this does not solve about account takeover

Session hijack is untouched: a stolen cookie replayed against your API renders no widget. Patient humans still get through.

Common questions about account takeover

How PrivCaptcha prices account takeover, and what it does not do about it.

Login, password reset and contact-change together. Takeover rarely starts at the login box, and protecting only the front door leaves account recovery as the cheapest way in.
No. We never store visitor IP addresses, so putting a challenge on account recovery does not build a fresh record of who attempted it.
Every request is challenged - there is no invisible pass to aim a script at, and no allowlist that skips the check. What changes is the form the challenge takes and what it costs. The server scores each request and picks one of five difficulty levels, so an ordinary visitor gets a couple of seconds and a client that looks automated gets tight tolerances and a heavier proof-of-work. On the non-visual path, taken by screen-reader and keyboard visitors, there is no puzzle to solve at all: the proof-of-work is the whole challenge, at a fixed 22 bits.
No. An address is used for the length of one request and never written anywhere. What we keep is an HMAC of it under a salt that is random, lives only in Redis and rotates every day, so yesterday's hashes cannot be linked to today's. The counters under that hash expire after 24 hours.

Put PrivCaptcha in front of your password reset form

10,000 verifications a month are free, and the integration is the one you already have.