What is account sharing?
Account sharing is when one set of login credentials is used across more people or devices than a plan allows — a password handed to friends, a single seat split across a team, or a subscription resold to many strangers. It shows up as one account appearing on more distinct devices and locations than a single user could plausibly produce.How ShieldLabs surfaces it
ShieldLabs resolves each authenticated session to a set of identifiers and grades how far an account has spread. Four layers answer four different questions:| Layer | What it answers | Where you read it | Latency |
|---|---|---|---|
| Identification | ”Is this the same device, and is it a new device or country for this account?” | The durable device_id on the webhook / History API | About a second |
| Anonymity detection | ”Is this session masked or anonymous right now?” | The signals array on the webhook / History API | About a second |
| Risk Score | ”How risky is the visit overall, as one 0-100 number?” | risk_score on the webhook / History API | About a second |
| Patterns | ”Has this account spread across many devices or countries over time?” | Dashboard Patterns + export | Background (~10 min) |
Account sharing is a policy question, not a fraud verdict. A family plan, a shared team login, and a resold credential can all look like “many devices on one account.” ShieldLabs tells you the spread; your terms of service decide what is allowed.
Prevent account sharing
The rule your code applies: for each account (UserHID), count the distinct devices and session countries you have seen, and when that count crosses your plan’s limit, step up verification, notify the account owner, or restrict the extra sessions instead of letting one credential run everywhere at once. Weigh a masked session more heavily — when a sharer hides behind a VPN to look local, the real network IP (local_ip) still exposes the network behind a faked public_ip.country, and detection_flags.ip_mismatch is set to true. ShieldLabs surfaces the spread and the Risk Score (0–100); your code owns the limit and the verdict. The steps below wire it up.
Build it
Create a ShieldLabs account and get your keys
Sign up for free and get 5,000 identifications, or log in if you already have an account. Register the domain you want to identify visitors on, then open the Keys page. Use the Public Key to initialize the snippet in the browser, and keep your server-side credentials on your backend: the Private API Key authenticates the History API, and each webhook endpoint has its own
whsec_… signing secret. See Keys.Identify authenticated sessions
Add the snippet to your app and call
checkAuthenticatedUser with the account’s hashed id (UserHID) on login and on sensitive actions. Pass a hash, never a raw email or user id.app.html
Check the device on every session
Read the scored result for that Read the real country behind a VPN. The webhook carries two geo readings.
RequestID from your webhook cache (the shared waitForScore helper), or fall back to the History API, then compare the DeviceID against the account’s known devices.api/session-check.js
public_ip.country comes from the public IP, which a VPN exit can put anywhere the sharer wants. local_ip.country is the visitor’s real network IP, which can reveal the network they are actually on. When the two disagree, detection_flags.ip_mismatch is set to true. So a credential whose public_ip.country roams while local_ip.country stays fixed is one masked location, not real spread — read the two together before you count an account’s countries.See the spread over time
Identification catches a new device right now. The harder signal is an account that quietly appears on a dozen devices, or from several countries within an hour. Patterns grade each account Suspicious, then Dangerous, as the linked count crosses thresholds in a rolling window (an account below the first threshold is the unflagged baseline). Levels never downgrade: once flagged Dangerous, new clean activity does not clear it.
Read these on the dashboard Patterns tab, or reconstruct the same counts live from the History API:
Many Devices on One Account
Many Devices on One Account
One account used from many different devices. The core account-sharing and account-resale shape. The grouping identity is the UserHID; the spread is counted in distinct DeviceIDs over a rolling window (default 30 days).
Multiple Countries on One Account
Multiple Countries on One Account
The same account active from several countries in a short window (24 hours). Catches a credential shared across regions, or one used behind rotating VPN exits. A real traveler can trip this, so read it with the device spread.
New Device and New Country
New Device and New Country
An existing account suddenly appears from a device and a country it has never used together. A strong account-takeover or hand-off signal, distinct from steady sharing.
Count devices and countries per account
Account History reads on
account.shieldlabs.ai and webhook delivery are free; the Management History path bills 1 request per returned row (an empty result still bills 1). For routine enforcement, use the dashboard pattern export as your watchlist and reserve billed Management reads for accounts you are actively investigating.Test it
Confirm the durable DeviceID holds before you wire policy to it. Log into one test account, then revisit the same machine in an incognito window, after clearing cookies, and from a second browser: thecookie_id and visitor_id change each time, but the device_id stays the same, so one machine does not look like three devices. Then log the same account in from a second physical device and watch a genuinely new device_id (and public_ip.country) appear — that is the real “new device” your check should act on.
Recommended starting policy
A guide, not a rule. The right device and country limits depend entirely on your product.| Signal | Suggested action |
|---|---|
| Known device, known country | Allow |
| New device, within your device limit | Notify the account owner, remember the device |
| New device, over your device limit | Require re-authentication on the new device |
| ”Multiple Countries on One Account” (Suspicious or Dangerous) | Step up verification, review against your sharing policy |
| ”New Device and New Country” (Dangerous) | Treat as possible takeover: force re-auth with the Login and 2FA step-up pattern |
Next: Acting on the Risk Score
The full decision playbook, including how to combine identity spread with the per-session Risk Score and its signals.