Intermediate LevelAuthentication & Authorization
Why should login Rate Limiting evaluate both IP address AND targeted User Account?
❓ Interview Prompt: Compare IP-based rate limiting vs account-based rate limiting vs distributed botnet credential stuffing.
Evaluating rate limiting using only a single key leaves major security loopholes:
The Blind Spots:
1
IP-Only Rate Limiting: An attacker using a distributed botnet (100,000 distinct IP addresses) submits 1 login attempt per IP against a target user account, bypassing IP limits completely!
2
Account-Only Rate Limiting: An attacker submits 1,000 bad logins targeting 'victim@company.com', triggering account lockout and creating a Denial of Service (DoS) for the legitimate user!
Dual Bucket Solution:
Evaluate rate limits using two parallel sliding window buckets:
•
Bucket 1: 'rate_limit:ip:<ip_address>' (e.g. max 20 attempts/min per IP).
•
Bucket 2: 'rate_limit:account:<username>' (e.g. max 5 attempts/min per account, triggering CAPTCHA rather than hard lockout).
Code Implementation Example
typescript
async function checkDualBucketRateLimit(ip: string, username: string): Promise<boolean> {
const ipKey = "rate:ip:" + ip;
const accountKey = "rate:account:" + username.toLowerCase();
const [ipCount, accountCount] = await Promise.all([
redis.incr(ipKey),
redis.incr(accountKey)
]);
if (ipCount === 1) await redis.expire(ipKey, 60);
if (accountCount === 1) await redis.expire(accountKey, 60);
return ipCount <= 20 && accountCount <= 5;
}💡Dual bucket rate limiting evaluating both client IP and target username.
🎯 Interview Key Takeaway
Combine IP rate limiting with target account rate limiting to block distributed botnet attacks without causing user account DoS.
#Rate Limiting#Redis#Security#Botnets#Intermediate
Back to all Authentication & Authorization Questions→