## 28) Login failure delay can enable app-layer DoS

Docs/Backend-Development.md

@@ -1907,7 +1907,7 @@ The login endpoint (`POST /api/auth/login`) is protected against brute-force att
 **Rate Limit Rules:**
 - **5 attempts per 60 seconds** per IP address.
 - Requests exceeding the limit return **HTTP 429 Too Many Requests** with a `Retry-After` header.
-- Each failed login triggers a 10-second server-side delay (`asyncio.sleep`) to further slow attacks, on top of bcrypt hashing (~100ms).
+- Each failed login triggers a progressive server-side delay (exponential back-off, 1–10 seconds) to further slow attacks, on top of bcrypt hashing (~100ms). The penalty grows with consecutive failures and resets after the rate-limit window expires. Concurrency protection caps the delay when multiple penalty tasks are already running for the same IP.
 
 **IP Extraction (Proxy Safety):**
 - When behind nginx, the rate limiter reads the real client IP from `X-Forwarded-For` or `X-Real-IP` headers.

Docs/Features.md

@@ -43,7 +43,7 @@ A web application to monitor, manage, and configure fail2ban from a clean, acces
 - The login endpoint (`POST /api/auth/login`) is protected against brute-force attacks with per-IP rate limiting.
 - **Rate limit:** 5 login attempts per minute per IP address.
 - When the limit is exceeded, the server returns **HTTP 429 Too Many Requests** with a `Retry-After` header indicating when requests will be accepted again.
-- Each failed login attempt triggers a 10-second delay on the server side to further slow down attack attempts, on top of the bcrypt password hashing cost.
+- Each failed login attempt triggers a progressive server-side delay (exponential back-off from 1 to 10 seconds) to further slow down attack attempts, on top of the bcrypt password hashing cost. The penalty grows with consecutive failures and resets after the rate-limit window expires.
 - The rate limiter tracks attempts in memory per IP, ensuring that rapid-fire attacks from a single source are quickly throttled.
 
 ---

Docs/Tasks.md

@@ -1,41 +1,3 @@
-## 27) Error response body shape is inconsistent
-- Where found:
-	- [backend/app/main.py](backend/app/main.py)
-	- [backend/app/routers](backend/app/routers)
-	- [frontend/src/api/client.ts](frontend/src/api/client.ts)
-- Why this is needed:
-	- Frontend cannot reliably branch on machine-readable error codes.
-- Goal:
-	- Standard error response schema with code + detail + metadata.
-- What to do:
-	- Add shared error model and update handlers.
-- Possible traps and issues:
-	- Legacy consumers parsing detail strings may break.
-- Docs changes needed:
-	- Add backend error schema and mapping table.
-- Doc references:
-	- [Docs/Backend-Development.md](Docs/Backend-Development.md)
-
----
-
-## 28) Login failure delay can enable app-layer DoS
-- Where found:
-	- [backend/app/routers/auth.py](backend/app/routers/auth.py#L110)
-- Why this is needed:
-	- Fixed 10-second await for invalid login attempts can amplify load impact.
-- Goal:
-	- Keep brute-force resistance without exhausting request capacity.
-- What to do:
-	- Replace fixed sleep with limiter-backed penalty strategy and concurrency protection.
-- Possible traps and issues:
-	- Too little penalty weakens brute-force protection.
-- Docs changes needed:
-	- Document authentication throttling strategy.
-- Doc references:
-	- [backend/app/utils/rate_limiter.py](backend/app/utils/rate_limiter.py)
-
----
-
 ## 29) Blocklist URL validation has DNS-rebinding window
 - Where found:
 	- [backend/app/utils/ip_utils.py](backend/app/utils/ip_utils.py#L145)