Security

Abuse protection

Authkits uses persistent account, IP, and challenge abuse controls around authentication and security-sensitive flows. It does not rely on a process-local counter that disappears when a worker restarts.

Account budgets

Persistent counters prevent repeated failures from being reset by a new browser session.

IP budgets

Request-aware flows can charge canonical client IP dimensions alongside account controls.

Challenge attempts

Verification, recovery, MFA, and step-up proofs have bounded attempts and expiry.

Bound challenge attempts

settings.py

AUTHKITS = {
    "SECURITY": {
        "CHALLENGE_TTL": 300,
        "CHALLENGE_MAX_ATTEMPTS": 5,
        "AUTHORIZATION_TTL": 120,
    },
}

Shared proofs are short-lived and attempt-bounded. Failed verification attempts and abuse charges are designed to commit even when the public operation is rejected.

Persistent abuse budgets

Login, verification, recovery, MFA, social handoff, and other sensitive operations reuse Authkits' database-backed abuse service. The current conservative policy denies the fifth charge in a five-minute window for protected dimensions rather than exposing arbitrary string-based "5/min" settings.

Trusted proxy handling

settings.py

AUTHKITS = {
    "SECURITY": {
        "TRUSTED_PROXIES": ["10.0.0.0/8", "192.0.2.10"],
    },
}

Forwarded client IPs are trusted only when the immediate proxy is explicitly configured. An empty list trusts none.

Fail closed under contention

Abuse checks use bounded database operations. If Authkits cannot safely establish the current budget under contention or a database failure, protected operations deny rather than silently bypassing the control.

Next steps

Review the audit trail produced by authentication and security changes.

Audit history