Brute-force Protection¶
This page describes GuardPost's built-in brute-force protection feature, including:
- Overview of the protection feature
-
InvalidCredentialsError -
RateLimiterclass — configuration and thresholds - Integration with
AuthenticationStrategy - Custom storage backends
Overview¶
Brute-force attacks against authentication endpoints (login forms, API key
checks, etc.) are a common threat. GuardPost provides a RateLimiter that
automatically tracks failed authentication attempts and blocks a client after
a configurable threshold is exceeded.
The mechanism works as follows:
- Your
AuthenticationHandlerraisesInvalidCredentialsErrorwhen presented with wrong credentials. AuthenticationStrategycatches this exception, increments the failure counter for the client, and re-raises (or blocks) as appropriate.- Once the failure count reaches the threshold, subsequent requests from the same client are rejected immediately without even calling the handler.
InvalidCredentialsError¶
InvalidCredentialsError is a subclass of AuthenticationError. Raise it
inside an AuthenticationHandler whenever you detect that credentials are
present but invalid (wrong password, revoked key, etc.).
Why a dedicated exception?
Using InvalidCredentialsError (rather than simply leaving context.identity
as None) lets AuthenticationStrategy distinguish between
"no credentials provided" (anonymous request — don't count) and
"wrong credentials provided" (brute-force attempt — do count).
RateLimiter¶
RateLimiter stores per-client failure counters and exposes a check method
that blocks clients that exceed the threshold.
| Parameter | Type | Default | Description |
|---|---|---|---|
max_attempts |
int |
5 |
Max failures allowed within duration seconds |
duration |
int |
300 |
Time window in seconds for the failure counter |
By default, counters are stored in memory — they do not persist across process restarts and are not shared between multiple processes. This is sufficient for single-process applications. See Custom storage backends for distributed setups.
Integration with AuthenticationStrategy¶
Pass a RateLimiter instance to AuthenticationStrategy to enable
brute-force protection automatically.
Expected output:
Attempt 1: InvalidCredentialsError — Bad credentials.
Attempt 2: InvalidCredentialsError — Bad credentials.
Attempt 3: InvalidCredentialsError — Bad credentials.
Attempt 4: TooManyRequestsError — Too many failed attempts from 10.0.0.1
Client identification
The rate limiter identifies clients using context.client_id if the property
exists, otherwise it falls back to the string representation of the context.
In web frameworks like BlackSheep, client_id is automatically mapped to the
client IP address.
Custom storage backends¶
The default in-memory storage is suitable for single-process applications. For distributed systems (multiple workers or processes), you need a shared store such as Redis.
You can implement a custom backend by subclassing RateLimiter and overriding
the get_attempts / increment_attempts methods:
Last modified on: 2026-03-10 20:06:58