Account takeover protection

Spot sign-ins that do not look like the real owner and challenge them before an attacker can empty a wallet or change credentials.

The problem#

Credential stuffing and phishing give attackers valid passwords. The login succeeds, so password checks alone cannot stop them. What differs is the context: a new country, an anonymising network, an automated client.

Signals to combine#

• IP reputation: isProxy, isTor, isBot and isHosting flags on the login IP.
• IP geolocation: country and ASN, to compare with the user's usual location.
• Email scoring when a user changes their email address.
• Phone validation when a user changes their phone or recovery number.

Gurdx does not hold your users' history, so keep each user's last known country and ASN in your own database and compare.

Integration flow#

1. After the password check passes, call IP reputation for the request IP with userID set to your user ID.
2. Compare the country and ASN against the user's stored profile.
3. Combine the signals into a decision: allow, ask for a second factor, or block and notify.
4. On sensitive actions (password, email or payout change) repeat the check and require re-authentication.
5. Update the stored profile only after a successful, verified sign-in.

async function loginRisk(user, ip) {
  const url = `https://gurdx.cretip.com/api/lookup/ip/threats?ip=${ip}&userID=${user.id}`;
  const res = await fetch(url, { headers: { Authorization: `Bearer ${process.env.GURDX_KEY}` } });
  const { status, data } = await res.json();
  if (status !== 'success') return 'review';

  const t = data.threats;
  let risk = 0;
  if (t.isTor) risk += 3;
  if (t.isBot) risk += 3;
  if (t.isProxy) risk += 2;
  if (t.isHosting) risk += 1;
  if (t.blacklisted) risk += 4;
  if (user.lastCountry && user.lastCountry !== data.countryCode) risk += 2;

  if (risk >= 5) return 'block';
  if (risk >= 2) return 'challenge';
  return 'allow';
}

Suggested actions#

The numbers above are examples you should adjust. Many honest users run VPNs, so a proxy flag alone should challenge, not ban.

Alerting#

Enable a webhook on proxy_detected events (internal type suspicious_ip) so your security team sees waves of suspicious logins, and add recurring attacker IPs to an IP blacklist.

Note: Scores and flags are signals. Pair them with rate limiting and breach-password checks rather than relying on a single check.

See also Multi-accounting.