ipasis
Blog/Technical Guide

Implementing Progressive Risk Challenges Using IP Reputation

February 12, 20264 min read

Binary security measures—allow or block—are insufficient for modern applications. They create friction for legitimate users and often fail to catch sophisticated abuse. Progressive risk challenges (also known as adaptive authentication) solve this by applying friction proportional to the risk associated with a request.

This guide details how to architect a progressive risk system using IP intelligence data from IPASIS.

The Logic of Graded Authentication

A progressive system evaluates the metadata of an incoming request (specifically the IP reputation) and assigns it to a risk tier. Each tier triggers a different response workflow:

  1. Low Risk (Green): Invisible authentication. The user proceeds without interruption.
  2. Medium Risk (Yellow): Friction introduced. Require MFA, email verification, or a CAPTCHA.
  3. High Risk (Red): Hard block or shadow-ban.

Designing the Risk Engine

To implement this, your backend must query the IPASIS API prior to processing critical actions (signup, checkout, login). Key signals to evaluate include:

  • Privacy Detection: Is the user behind a VPN, Tor exit node, or Proxy?
  • ISP Type: Is the traffic originating from a residential ISP (low risk) or a hosting provider/data center (high risk)?
  • Abuse Score: Historical behavior associated with the IP.

Signal Evaluation Matrix

| Signal Combination | Risk Level | Action | | :--- | :--- | :--- | | Residential ISP + Clean History | Low | Allow | | Data Center + No VPN detected | Medium | 2FA / CAPTCHA | | Detected Proxy / VPN | High | CAPTCHA + Email Verify | | Known Abuse History | Critical | Block |

Implementation Example

The following Python example demonstrates a middleware function that intercepts a login request, queries IPASIS, and determines the necessary authentication flow.

import requests
from flask import Flask, request, jsonify

app = Flask(__name__)

IPASIS_API_KEY = "your_ipasis_key"

def get_ip_reputation(ip_address):
    url = f"https://api.ipasis.com/v1/reputation?ip={ip_address}&key={IPASIS_API_KEY}"
    try:
        response = requests.get(url, timeout=2)
        return response.json()
    except Exception as e:
        # Fallback: log error and default to medium risk to be safe
        return None

def determine_risk_action(ip_data):
    if not ip_data:
        return "CHALLENGE_CAPTCHA" # Fail closed/safe

    # High Risk: Known attackers or Tor nodes
    if ip_data.get('is_tor') or ip_data.get('risk_score') > 80:
        return "BLOCK"

    # Medium Risk: Data centers or Proxies
    if ip_data.get('is_proxy') or ip_data.get('asn_type') == 'hosting':
        return "CHALLENGE_2FA"

    # Low Risk: Residential traffic
    return "ALLOW"

@app.route('/login', methods=['POST'])
def login_handler():
    client_ip = request.remote_addr
    
    # Step 1: Assess Risk
    ip_data = get_ip_reputation(client_ip)
    action = determine_risk_action(ip_data)

    # Step 2: Execute Logic
    if action == "BLOCK":
        return jsonify({"error": "Access denied due to high risk IP."}), 403
    
    if action == "CHALLENGE_2FA":
        # Trigger frontend to show 2FA modal
        return jsonify({"status": "challenge_required", "type": "2fa"}), 200

    # Step 3: Proceed with standard login
    # (Login logic here...)
    return jsonify({"status": "success", "token": "xyz..."}), 200

Tuning for Business Logic

Not all "high risk" signals apply to every business model. You must tune thresholds based on your specific use case:

  • B2B SaaS: Developers often use VPNs. Blocking all proxies may result in high false positives. In this context, treat VPNs as "Medium Risk" (challenge) rather than "High Risk" (block).
  • E-Commerce: Hosting IPs making credit card transactions are almost always fraudulent. These should be treated as "Critical Risk."

FAQ

Q: How does this impact API latency? A: IPASIS endpoints are globally distributed with sub-millisecond processing. However, it is best practice to set a strict timeout (e.g., 200ms) on the external request and fail-safe (default to a challenge) if the API is unreachable.

Q: Can I cache the results? A: Yes. IP reputation is relatively sticky. Caching results in Redis for 10-15 minutes reduces API costs and latency without significantly compromising security.

Q: What about IPv6? A: Progressive risk challenges are critical for IPv6, as IP rotation is easier for attackers. IPASIS fully supports IPv6 reputation scoring.

Integrate IP Intelligence Today

Static firewalls are no longer enough. By implementing progressive risk challenges, you reduce friction for 99% of your users while effectively neutralizing automated threats.

Start building smarter security workflows with the IPASIS API. Get your free API key here.

Start detecting VPNs and Bots today.

Identify anonymized traffic instantly with IPASIS.

Get API Key