Brute-Force Protection
debt(d5/e5/b5/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list Semgrep as the tool, with a specific code pattern targeting login/authenticate methods missing a rate-limit check before password_verify(). This is not a default linter check but requires a specialist SAST rule, and the absence of protection is silent in production until attacks occur — Semgrep brings it to d5 rather than d7/d9.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix requires adding a Redis-backed attempt counter keyed by username, configuring block durations, and then applying the same logic to password-reset endpoints. This spans at least authentication, password-reset, and infrastructure/cache layers — more than a single-line patch (e1/e3) but not a full architectural rework (e7+).
Closest to 'persistent productivity tax' (b5). Brute-force protection must be consistently applied across all authentication surfaces (login, password reset, MFA). Every new authentication-adjacent feature must be reviewed to ensure the rate-limiting layer is present, creating an ongoing maintenance obligation across multiple workstreams without necessarily defining the entire system's shape.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The canonical misconception is that IP-based rate limiting alone is sufficient, which is exactly what most developers naturally reach for first (mirroring how general API rate limiting works). The per-account attempt counting requirement contradicts the intuitive IP-centric mental model, and the common_mistakes list reveals multiple serious non-obvious failure modes: permanent lockout as a DoS vector, unprotected reset endpoints, and username enumeration via error messages.
Also Known As
TL;DR
Explanation
Brute-force attacks submit large volumes of credential combinations to authentication endpoints until one succeeds. Defence layers: (1) Rate limiting — restrict attempts per IP and per account (e.g. 5 failures per 10 minutes) using a token-bucket or sliding-window counter stored in Redis or APCu. (2) Progressive delays — exponential back-off after each failure slows automated tools without locking legitimate users out permanently. (3) Account lockout — temporarily disable an account after N failures; prefer time-based lockout over permanent to avoid denial-of-service. (4) CAPTCHA — challenges that are easy for humans and hard for bots, triggered after a threshold of failures. (5) MFA — a second factor renders the guessed password alone useless. In PHP, rate limiting is typically implemented in middleware or a firewall layer before the authentication logic. Credential stuffing (using breached credential databases) is a variant — defeated by checking submitted passwords against known-breached lists (HaveIBeenPwned API). Timing-safe comparison (hash_equals) prevents timing-based oracle attacks that can leak valid usernames.
Watch Out
Common Misconception
Why It Matters
Common Mistakes
- Rate limiting only by IP — attackers distribute requests across thousands of IPs; always also count per-username.
- Permanent account lockout — creates a denial-of-service vector where an attacker locks every account by deliberate failures.
- Not applying rate limits to password-reset endpoints — reset flows are equally brute-forceable and often less protected.
- Leaking whether a username exists via different error messages — use a generic 'invalid credentials' message regardless of which field is wrong.
Code Examples
// No rate limiting — unlimited attempts:
public function login(string $email, string $password): bool {
$user = User::findByEmail($email);
return $user && password_verify($password, $user->password_hash);
}// Redis-backed per-account rate limit:
public function login(string $email, string $password): bool {
$key = 'login_attempts:' . hash('sha256', $email);
$attempts = (int) $this->redis->get($key);
if ($attempts >= 5) {
throw new TooManyAttemptsException('Account temporarily locked');
}
$user = User::findByEmail($email);
if (!$user || !password_verify($password, $user->password_hash)) {
$this->redis->incr($key);
$this->redis->expire($key, 900); // 15 min window
throw new InvalidCredentialsException('Invalid credentials');
}
$this->redis->del($key); // reset on success
return true;
}