UserHID you have seen many times before, arriving on a DeviceID you have never seen for it, often from a new country or behind a datacenter, VPN, or Tor session. ShieldLabs gives you the durable DeviceID to recognize the device and the Risk Score to read the session’s anonymity, so your login code can step up to a second factor exactly when the device or location does not fit the account.
Device continuity
The server-derived DeviceID is durable: it survives cleared cookies, incognito, and IP rotation, so a returning customer keeps the same id and an intruder’s machine shows up as a new one.
Session anonymity
The per-request Risk Score folds datacenter, VPN, proxy, Tor, and anti-detect signals into one number, raising the takeover risk when the session is masked.
This recipe is the device-and-location half of login security. The step-up 2FA recipe owns the threshold ladder that turns a risky login into a second-factor challenge, and the credential stuffing recipe owns throttling the flood of attempts by DeviceID. This page assumes both and only carries the device-comparison logic that is unique to takeover.
The takeover signal: a new device on a known account
A first-time login looks the same to your password check whether it is the real owner on a new laptop or an intruder with a stolen password. The difference is in the history. Before issuing the session for an established account, pull the devices and countries thatUserHID has used before and compare them to the one in front of you right now.
The cheap, durable comparison key is the DeviceID. It is derived server-side from stable device characteristics, so it stays the same when the visitor clears cookies, opens an incognito window, or rotates their IP, and an intruder on a different machine cannot reproduce it. A UserHID that has only ever appeared on one or two DeviceIDs, now logging in from a third, is the core takeover shape.
Compare the login device against the account's history
shieldHistory is the same GET /history/{type}/{value} read the other recipes use, here keyed by user_hid to pull the account’s own recent sessions. The response is an array of snapshots, newest first, each carrying the DeviceID, Country, and Score for that session.
The account's recent devices and countries
A blocked or JavaScript-disabled browser returns the all-zero DeviceID (
00000000-0000-0000-0000-000000000000) and a fixed Risk Score of 90, since the device characteristics needed to derive a stable id were never collected. Route that login to verification on the score alone, and skip the new-device comparison for it. The all-zero id is the absence of a device, so never count it as a new one.Wire it into your login gate
The verdict combines the device comparison with the session’s anonymity. A new DeviceID on its own can be a real customer’s new phone. A new device and a new country, or a new device and datacenter or Tor signals on the session, is the combination worth a step-up. The step-up 2FA recipe owns the band ladder; here it is the inputs that change the rung.api/login.js escalate a takeover-shaped login
Watch the takeover patterns on the dashboard
The History read above reconstructs one account’s device history on demand. For the standing view across all accounts, the dashboard Abuse Patterns compute the same shapes historically and grade each flagged account Suspicious, then Dangerous, as the evidence accumulates. Below the Suspicious threshold an account is the unflagged baseline, which is never recorded or emitted. Patterns are dashboard-only; they do not ride on the webhook.New Device and New Country
New Device and New Country
An account appearing from a
(device, country) combination it has never used before. The closest single pattern to a takeover, and the one to watch first: pull its flagged UserHIDs and feed them into a step-up watchlist.Many Devices on One Account
Many Devices on One Account
One account reached from many distinct devices over the window. A spread that can mean a shared or resold account, and at the high end an account being worked from a string of new machines.
Multiple Countries on One Account
Multiple Countries on One Account
The same account appearing from several countries in a short span, the impossible-travel shape that VPN hopping and a hijacked session both produce.
Changing IDs on One Account
Changing IDs on One Account
An account whose DeviceID or VisitorID keeps changing, a hint of anti-detect tooling cycling its environment between attempts to look like a new visitor each time.
Identity continuity rests on the DeviceID, not the VisitorID. The DeviceID is durable across a cookie clear; the VisitorID is recomputed from the device and a browser cookie, so clearing cookies gives the same browser a fresh VisitorID. Compare the device a
UserHID arrives on against the DeviceIDs it has used before, and treat a VisitorID change as a weaker hint, not the primary key.Recommended starting policy
A guide, not a rule. Layer the conditions: a takeover login trips more than one, and friction should rise as they stack.| Condition for an established account | Suggested login action |
|---|---|
| Known DeviceID, clean session (Score under 30) | Allow |
| New DeviceID, otherwise clean | Require a second factor |
| New DeviceID and new Country | Require strong verification, alert the owner |
| New DeviceID and High-band anonymity (datacenter, VPN, Tor) | Require strong verification, alert the owner |
| All-zero DeviceID (blocked or JS-disabled, fixed Score 90) | Route to verification on the score alone |
| UserHID on the “New Device and New Country” Dangerous watchlist | Step up on every session until reviewed |
Next
Step-up 2FA on Risky Logins
The threshold ladder this recipe escalates into: when a risky login becomes a second-factor challenge.
Slow Down Credential Stuffing
The other login defense: throttle the flood of attempts on the durable DeviceID before takeover is even on the table.