Brute-Force Protection

Authentication endpoints should limit repeated attempts to reduce password guessing and credential attacks. A backend typically combines rate limits, temporary delays or lockouts, and monitoring while avoiding controls that create easy denial-of-service targets.

Brute-force protection limits how quickly an attacker can try credentials against an authentication endpoint. Without it, an attacker can repeatedly submit password guesses or reused credentials until one succeeds.

A common implementation applies a limit over a time window, such as allowing only a bounded number of failed attempts from an IP address, account, or other key. In Java backends, this can be implemented with an in-memory mechanism for a single instance or a shared store such as Redis when multiple application instances must enforce the same limit.

The limiting key matters. IP-only limits can punish users behind shared networks, while account-only limits can let an attacker target many accounts from one source. Practical systems often combine several signals and choose limits that slow attacks without unnecessarily blocking legitimate users.

Responses should also avoid revealing whether an account exists. A temporary delay, generic authentication error, progressive throttling, and security logging can work together. Permanent account lockouts require particular care because an attacker could deliberately trigger them for other users.

Key points

• Throttle repeated authentication failures rather than accepting unlimited guesses.
• Choose rate-limit keys carefully; IP-only and account-only controls have different weaknesses.
• Use a shared limiter such as Redis when enforcement must work across multiple application instances.
• Return generic authentication errors so attackers cannot easily enumerate valid accounts.
• Log throttling and suspicious authentication activity for detection and investigation.

Interview questions

Why might Redis be preferable to an in-memory counter?

An in-memory counter belongs to one application process, so another instance may not know about the attempts. Redis can provide a shared state that multiple application nodes can consult. It also supports expiration and atomic operations useful for rate-limiting designs.

What would you use as the key for a login rate limiter?

I would avoid relying on a single dimension. An IP address can represent many legitimate users, while an account identifier can be targeted by many different IPs. Depending on the threat model, I would combine signals such as account identity and source address and apply different thresholds to each.

Why should a login endpoint have brute-force protection?

Without a limit, an attacker can submit a large number of password guesses against an account. Throttling reduces the number of guesses possible in a given period and therefore raises the cost of online attacks. It should complement, rather than replace, strong password storage and other authentication controls.

How would you design brute-force protection without making account denial-of-service easy?

I would avoid a simple permanent account lock after a small number of failures. Instead, I would use progressive throttling with multiple dimensions, such as account and source, and apply increasing delays or temporary restrictions as suspicious activity grows. I would also monitor the events and provide recovery mechanisms for legitimate users.