Account Protector

The problem it solves

Credential stuffing succeeds because billions of username/password pairs are already public and password reuse is universal. The attacker does not need to break your authentication; they need to use it, at scale, with valid credentials. From the application's point of view every request is a correct login. Rate limits and CAPTCHAs raise the cost, but sophisticated operators distribute across residential proxies, solve challenges through farms, and pace themselves below any static threshold.

Account Protector sits in front of the account lifecycle and answers a question ordinary bot detection cannot: not “is this a human?” but “is this the human who owns this account?”

Attack patterns covered

User profiles and population profiles

Account Protector's core mechanism is comparison against two learned baselines, evaluated together on every scored request.

User profile (individual baseline)

For each known user identifier, the platform builds a profile of how that specific account normally authenticates:

• Devices and browsers — the fingerprints previously seen for this user, and how long each has been known.
• Networks — typical IP addresses, ASNs, connection types (residential, mobile, corporate, hosting/proxy).
• Geography — usual countries and regions, and the plausibility of travel between consecutive logins.
• Timing — the hours and days on which this account is normally active.
• Behaviour — how the user interacts with the login form: typing cadence, pointer use, form-fill patterns, paste behaviour.

A login that matches the profile is low risk even from an unusual place. A login that contradicts it — new device and new country and hosting-provider IP and pasted credentials at 03:00 — is high risk even with the correct password.

Population profile (site-wide baseline)

Simultaneously, the platform models what normal traffic looks like across your whole user base: the usual mix of device types, browser versions, operating systems, ASNs, countries, and the usual login success/failure ratio. This catches the attack that no individual profile can see — a campaign in which each account is touched only once or twice, but the campaign as a whole is statistically impossible: an implausible concentration of one browser build, or a sudden surge of first-time devices from a single ASN.

Risk scoring

Each scored request produces a user risk score accompanied by risk factors — the specific reasons the score was raised. The factors matter as much as the number: they are what makes the score explainable to a fraud team and actionable in a rule.

Telemetry and user identification

Two integration inputs make the whole product work, and both need engineering attention early.

1. Client-side telemetry

• JavaScript on login, registration and account pages collects device, browser and interaction signals, which the edge combines with network and request evidence.
• Verify the script actually loads and executes on every protected page, including those rendered inside modals, iframes or a separate identity-provider domain.
• A Content Security Policy that blocks the script silently removes an entire evidence class — those sessions get scored on network signals alone.
• Native mobile apps need the equivalent SDK-based collection; otherwise your own app traffic looks like a scripted client.

2. The user identifier

• Account Protector must be told which part of the request carries the user identity — a form field, JSON body field, header or cookie.
• Extraction has to be correct for every login variant you operate: standard form post, JSON API login, social login callback, mobile app login, and any legacy path.
• Identifiers should be normalised (case, whitespace, alias forms of the same email) so one human maps to one profile.
• Hash the identifier where policy requires it, so profiles are keyed on a pseudonymous value rather than a raw email address. Hashing must be consistent across every login path, or the same user fragments into several profiles.

Endpoints to protect

Protection scope should follow the whole account lifecycle, not just the login form. Attackers move to whichever endpoint is unmonitored.

Rules, actions and exceptions

Policy is expressed as rules that combine the risk score, the risk factors and the endpoint in question, and then apply an action.

Available actions

Allow lists and exceptions

• Your own automation — synthetic login monitors, test accounts, CI end-to-end suites. These will otherwise be your first and loudest false positives.
• Corporate egress — call-centre agents legitimately signing into many customer accounts from one IP, and staff shared-desktop environments.
• Declared third parties — aggregators and partners with a contractual right to access accounts on a user's behalf; allow-list by identity, not just IP.
• Known migration events — a platform cut-over or forced password reset creates a legitimate surge of first-time devices; plan an exception window rather than absorbing the false-positive spike.

Graduated response

The correct action depends on both the score and the value of what is being attempted. The same score should not produce the same outcome on a browse action and a payout change.

Forwarding the score to the origin is usually the most valuable integration: the application already knows the account's value, tenure, balance and MFA status, and can combine those with the score far more intelligently than an edge rule can.

Reports and investigation

• Risk distribution over time — the shape of scoring across logins, with campaign spikes clearly visible against the baseline.
• Risk factor breakdown — which factors are driving scores. If one factor dominates every high score, verify it is not a misconfiguration (for example, all traffic appearing to come from one IP because a proxy in front of Akamai is not forwarding the client address).
• Top targeted accounts — accounts under sustained attack, which are the ones worth proactively protecting or contacting.
• Attack source view — ASN, geography and device clustering, to distinguish one operator from many.
• Would-have-blocked analysis — in monitor mode, the volume a rule would have actioned. This is the evidence you need before enforcing.
• Failure ratio — the login success/failure balance per endpoint is often the earliest visible sign of a stuffing campaign.

Rollout

1. Map every authentication path before configuring anything: web, mobile, API, social login, partner SSO, legacy endpoints. Anything unmapped is unprotected.
2. Configure and verify user-ID extraction on each of those paths, with consistent normalisation and hashing.
3. Deploy telemetry collection and confirm the script or SDK executes on every protected surface.
4. Run in monitor mode through the learning period. Profiles need enough logins per user to be meaningful; low-frequency accounts (annual renewals, seasonal shoppers) take considerably longer than daily-active users.
5. Build the allow lists for your own automation, corporate egress and declared third parties.
6. Analyse the score distribution and identify the natural break between routine and anomalous logins for your population.
7. Start with the highest-value, lowest-volume actions — payout and email changes — where a step-up is cheap and a false positive costs one support call rather than thousands.
8. Introduce step-up authentication on medium risk at login, measuring the completion rate. Step-up that genuine users abandon is a revenue problem disguised as a security control.
9. Enable denial for high risk only once you can show, from data, what it would have blocked over the prior fortnight.
10. Review weekly. Support tickets about blocked logins are the ground-truth false-positive signal, so build that feedback path before you enforce.

Developer tools