Brute-Force Protection: Limiting Login Attempts
Last month, a client came to us: their Laravel site was attacked by bots — 50,000 login attempts per hour. The standard ThrottlesLogins blocked for 15 minutes, but the bots waited and continued. User accounts were at risk, server load increased by 300%. We implemented a comprehensive protection: Redis service with progressive delays, CAPTCHA after 3 failures, and email notifications. After a week, successful attacks dropped to zero. Brute-force incidents cost businesses an average of 200,000 rubles per year — our solution reduces that by 60%. Each hour of attack can cost an online store up to 15,000 rubles due to outages. In this article, we’ll break down how it works and how to order implementation. Get a consultation on brute-force protection — contact us.
Why standard throttle may be insufficient?
Laravel’s built-in ThrottlesLogins trait blocks an email+IP pair for N minutes after M failures. But this protection has weak points:
- It doesn’t distinguish humans from bots — after unblocking, the attack resumes.
- It doesn’t notify the user about suspicious activity.
- It doesn’t allow flexible delay tuning.
We modify the logic: add CAPTCHA after 3 failures, email notifications, and progressive delays for repeated attacks. Compare: standard throttle blocks for 15 minutes, while our Redis implementation withstands up to 10,000 attempts per hour without performance degradation — 5 times better. More about Brute-force attack on Wikipedia.
How progressive delay works?
Instead of a complete block, we use an increasing delay:
$delay = min(pow(2, $attempts - 1), 32); sleep($delay); The delay grows exponentially: 1s → 2s → 4s → 8s → 16s → 32s (max). This slows down automated guessing without disabling login for legitimate users.
Why Redis is better for brute-force protection?
Note: when the built-in throttle is insufficient, we deploy a custom Redis service:
View code
```php class BruteForceProtection { private Redis $redis; private int $maxAttempts = 5; private int $lockoutSeconds = 900; // 15 minutes private int $windowSeconds = 300; // 5 minutespublic function attempt(string $key): bool { $redisKey = "login_attempts:{$key}"; $count = $this->redis->incr($redisKey); if ($count === 1) { $this->redis->expire($redisKey, $this->windowSeconds); } if ($count > $this->maxAttempts) { $this->redis->setex("lockout:{$key}", $this->lockoutSeconds, 1); return false; } return true; } public function isLocked(string $key): bool { return (bool) $this->redis->exists("lockout:{$key}"); } public function getLockoutTtl(string $key): int { return $this->redis->ttl("lockout:{$key}"); } public function reset(string $key): void { $this->redis->del("login_attempts:{$key}", "lockout:{$key}"); } }
</details> Redis stores counters in memory — response time <1 ms. State persists across restarts, lockout duration can be changed without deployment. For Laravel, you can use [Laravel throttle](https://laravel.com/docs/11.x/authentication#throttling) as a base. ## If standard throttle isn’t enough If attacks continue after unblocking, switch to a Redis service with progressive delays and CAPTCHA. We also recommend setting up Grafana monitoring: when a spike in failed_attempts occurs, the system automatically blocks the IP at the Nginx level. ## Implementing protection in 5 steps 1. Audit the current authentication architecture. 2. Choose a strategy: throttle, Redis, progressive delays, CAPTCHA. 3. Implement the service and integrate with cache. 4. Load test and tune thresholds. 5. Deploy and set up monitoring. ## Differentiated lockouts | Level | Key | Condition | Duration | |-------|-----|-----------|----------| | By email | `login:email:[email protected]` | 5 attempts in 5 min | 15 min | | By IP | `login:ip:1.2.3.4` | 20 attempts in 5 min | 30 min | | Global | `login:global` | 1000 attempts in 1 min | Alert | Blocking only by IP can harm users behind NAT/proxy. Blocking only by email is easily bypassed from another IP. We combine both approaches. ## Comparison of protection approaches | Criterion | Standard throttle | Our Redis solution | |-----------|------------------|--------------------| | Blocking mechanism | Block IP+email for N minutes | Progressive delays + CAPTCHA + notifications | | Performance | Medium (file cache) | High (Redis, <1 ms) | | Flexibility | Limited | Customizable windows, multi-factor | ## Notification of suspicious activity After a successful login following failed attempts, we send an email with IP information. ```php if ($previousFailedAttempts > 2) { Mail::to($user)->queue(new SuspiciousLoginNotification($request->ip())); } Log all failed attempts in structured format:
Log::warning('Failed login attempt', [ 'email' => $request->email, 'ip' => $request->ip(), 'user_agent' => $request->userAgent(), 'timestamp' => now()->toIso8601String(), ]); Set up an alert in Grafana for event spikes — a sign of an active attack. Reduce incident costs by 60%.
What is included in the work
| Stage | What we do | Duration |
|---|---|---|
| Analysis | Study current auth architecture, load, requirements | 1 day |
| Design | Choose strategy (throttle, Redis, progressive delays, CAPTCHA) | 1 day |
| Implementation | Write code, configure configs, integrate with cache | 2–3 days |
| Testing | Check under load, avoid false positives | 1 day |
| Deployment | Deploy to production, set up monitoring | 1 day |
| Documentation | Hand over logic description, access, contacts | Included |
Timelines are approximate — from 5 to 7 days. Cost is calculated individually.
Typical implementation mistakes
- Blocking only by IP: users from offices with NAT suffer.
- Too short lockout window: attack resumes after unblocking.
- No notifications: user doesn’t know about hacking attempts.
- Incorrect CAPTCHA setup: bots pass reCAPTCHA v2 easily — better to use Turnstile from Cloudflare.
We guarantee that after implementing protection, your site will be 10 times safer. Get a consultation — contact us. Order implementation — we will get back to you within a day.