Build1 publisher3 min readPublished
Cloudflare's new fraud dashboard judges each account against its own login history
Cloudflare launched an Early Access fraud dashboard built on per-account login and signup histories, arguing AI-faked identities now beat one-time checks. How much it catches depends on how much of a site's login traffic Cloudflare's edge actually sees.
The Engineer · Build desk
What happened
- Every login or signup adds the event plus network and device signals seen at Cloudflare's edge, building the baseline that deviations are measured against.
- The population view reports login and signup volume, account counts, unique IPs and devices, and breakdowns by country and ASN.
- In Cloudflare's credential stuffing example, analysts start at that overview and drill into individual account histories to reconstruct what happened.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Per-account baselines cannot judge a fresh synthetic signup, so sites fighting fake account creation depend on AAP's cross-account clustering at the moment of signup.
- exposure Login paths that bypass Cloudflare's edge never reach the account record, so any account history AAP builds has gaps wherever a site routes traffic around Cloudflare.
- decision The identifier a site configures decides what AAP counts as one account, making the choice between email, username and phone a fraud-design decision taken at integration time.
Cloudflare puts its case in two sentences: "One convincing interaction can be faked. A consistent pattern of legitimate behavior is much harder to manufacture." [3] A point-in-time check asks "Can this person pass the check right now?" The stateful model adds "Does it fit what we know about this account and its established behavior?" [4] The reason Cloudflare gives is that AI lets fraudsters pair exposed credentials with synthetic media built to get past identity verification [2].
For that argument to hold on a given site, keeping up a legitimate-looking history has to cost an attacker more than passing one liveness check. "Much harder" is Cloudflare's phrase, and the post does not put a figure on it [3].
The design is simple to describe. The site configures an identifier from its login or signup flow, such as an email address, username or phone number. Cloudflare cryptographically hashes it into a per-domain Hashed User ID [5]. Each login or signup is appended to that ID, along with the network and device signals Cloudflare observed at its edge [6]. Cloudflare calls the ID privacy-preserving [5]. Deviations are measured against whatever that record has accumulated [6].
That accumulation takes time [6]. A brand-new account has no record at its first signup, so per-account deviation detection has nothing to compare it against [1]. For signups, the dashboard compares accounts with each other. One question it is built to answer is "Did a sudden signup increase coincide with shared characteristics?" [10] That check works across the population and needs no single account's history.
The record also has edges. It holds only what Cloudflare sees at its edge, within the login and signup flows a site has configured [6] [7]. A login path that bypasses Cloudflare adds nothing to an account's history. Neither does a flow nobody configured [2].
The dashboard itself is a funnel [11]. The population view shows total login and signup volume, how many accounts produced it, unique IP addresses and devices, and country and ASN breakdowns [8]. Analysts can track failed logins and leaked credential matches and rank accounts by login failure rate [9]. In Cloudflare's credential stuffing walkthrough, the team starts at that overview. It then drills into individual accounts, whose view carries the history needed to reconstruct what happened [12].
I think the order is right. A team facing a stuffing campaign needs the campaign's scope before it picks accounts for manual review. The population view gives that scope without opening every account [11]. Anyone who has worked a breach from a spreadsheet of usernames will recognise the problem this design avoids. The dashboard is available first to Early Access customers [7].
What to watch
- Any measurement from Cloudflare of how often per-account history flags synthetic identities that had already passed identity verification.
- Whether AAP extends beyond login and signup to flows such as password reset, where a taken-over account acts after it is in.
- General availability terms and pricing once the Early Access period ends.