The Hidden Vulnerabilities in Your Authentication System: A Deep Dive into Timing Attacks, IP Spoofing, and Race Conditions

How we discovered and fixed critical security flaws that most authentication systems overlook

Introduction
Authentication is the foundation of application security.

Yet, many developers even experienced ones overlook subtle vulnerabilities that can expose user data, enable account enumeration, or allow attackers to bypass rate limiting.

Over the past few months, I've been working on hardening an authentication service, and what I discovered shocked me: three critical vulnerabilities that are surprisingly common in production systems.

In this article, I'll walk you through these vulnerabilities, explain why they're dangerous, and show you how to fix them. Whether you're building your own auth system or evaluating third-party solutions, understanding these issues is crucial.

Vulnerability #1: Timing Attacks on Password Verification
The Problem
Imagine an attacker trying to guess a user's password.
They send login requests with different passwords and measure the response time.

If the server takes longer to respond when the username exists (even with a wrong password), the attacker knows the account exists. This is called a timing attack.

Here's what was happening in our code:

The vulnerability: When a user doesn't exist, the function returns immediately. When a user exists but the password is wrong, it performs the expensive password verification first.
This timing difference leaks information.

Why It Matters

Account Enumeration: Attackers can determine which email addresses are registered
User Privacy: Violates privacy by revealing account existence
Targeted Attacks: Attackers can focus on known accounts
The Fix
We implemented constant-time verification by always performing password verification, even for non-existent users:

// SECURE CODE
const user = await findUserByEmail(email);
const DUMMY_HASH = '$argon2id$v=19$m=65536,t=3,p=4$...'; // Pre-computed hash

// Always perform both verifications in parallel
const [, realResult] = await Promise.all([
  verifyPassword(DUMMY_HASH, DUMMY_PASSWORD), // Dummy verification (always fails)
  user && user.passwordHash 
    ? verifyPassword(user.passwordHash, input.password)
    : verifyPassword(DUMMY_HASH, DUMMY_PASSWORD), // Dummy if no user
]);

if (!user || !user.passwordHash || !realResult) {
  throw new AuthError('Invalid credentials');
}

Key improvements:

Both paths take similar time (constant-time execution)
No information leakage about user existence
Parallel execution maintains performance
Vulnerability #2: IP Spoofing in Rate Limiting
The Problem
Rate limiting is essential for preventing brute-force attacks. However, many implementations trust the X-Forwarded-For header directly, which can be easily spoofed by attackers.

// VULNERABLE CODE
const ip = req.headers['x-forwarded-for']?.split(',')[0] || req.ip;
// Use IP for rate limiting

The vulnerability: Attackers can send fake X-Forwarded-For headers to bypass rate limits or frame innocent users.

Why It Matters
Bypass Rate Limits: Attackers can make unlimited requests
IP Spoofing: Frame legitimate users by using their IPs
DDoS Amplification: Distribute attacks across multiple fake IPs
The Fix
We fixed this by relying on Express's built-in req.ip, which respects the trust proxy setting:

// SECURE CODE
// In app.ts - configure trust proxy properly
if (env.nodeEnv === 'production') {
  app.set('trust proxy', true); // Trust reverse proxy
} else if (process.env.TRUST_PROXY) {
  app.set('trust proxy', process.env.TRUST_PROXY);
}

// In rate limiter
keyGenerator: (req) => {
  // req.ip respects 'trust proxy' setting
  // Express validates X-Forwarded-For when trust proxy is configured
  return req.ip || 'unknown';
}

Key improvements:

Express validates proxy headers when trust proxy is set
No manual header parsing (which can be spoofed)
Proper configuration for production deployments

Vulnerability #3: Race Condition in OTP Verification
The Problem
When verifying one-time passwords (OTPs), there's a critical window between checking if an OTP is valid and marking it as used.
An attacker can exploit this with concurrent requests.

// VULNERABLE CODE (TOCTOU - Time of Check, Time of Use)
const otp = await findOTP(userId, code);

if (!otp || otp.used || otp.expiresAt < new Date()) {
  throw new AuthError('Invalid OTP');
}

// ⚠️ RACE CONDITION WINDOW: Another request could verify the same OTP here

await markOTPAsUsed(otp.id);

The vulnerability: Two simultaneous requests can both verify the same OTP before either marks it as used.

Why It Matters
OTP Reuse: Attackers can use the same OTP multiple times
Security Bypass: Defeats the purpose of one-time passwords
Account Takeover: Multiple login sessions from a single OTP

The Fix
We used an atomic database operation to verify and mark as used in a single transaction:

// SECURE CODE
const result = await prisma.emailOTP.updateMany({
  where: {
    userId: user.id,
    code,
    used: false,
    expiresAt: { gt: new Date() }, // Check expiry DB-side
  },
  data: {
    used: true, // Atomic update
  },
});

if (result.count === 0) {
  throw new AuthError('Invalid or expired OTP code');
}

Key improvements:

Atomic operation (verify + mark as used in one query)
Database-level expiry check
No race condition window
Only one request can succeed per OTP
Bonus: Distributed Rate Limiting with Redis
While fixing these vulnerabilities, we also improved our rate limiting architecture by moving from in-memory to Redis-backed distributed rate limiting.

Why This Matters

Horizontal Scaling: Rate limits work across multiple server instances
Consistency: Same limits apply regardless of which server handles the request
Resilience: Graceful fallback to memory store if Redis is unavailable

// Redis-backed rate limiting with fallback
const redisClient = new Redis({
  host: env.redis.host,
  port: env.redis.port,
  password: env.redis.password,
  retryStrategy: (times) => Math.min(times * 50, 3000),
});

redisClient.on('error', (error) => {
  logger.warn('Redis connection error, falling back to memory store');
  // express-rate-limit automatically falls back to memory store
});

The Impact: Before vs. After
Before
❌ Timing attacks could enumerate user accounts
❌ Rate limiting could be bypassed via IP spoofing
❌ OTPs could be reused through race conditions
❌ Rate limiting only worked per-server instance
After
✅ Constant-time password verification (no information leakage)
✅ Proper IP handling with Express trust proxy
✅ Atomic OTP verification (no race conditions)
✅ Distributed rate limiting with Redis

Best Practices for Authentication Security

Based on our experience, here are the key principles every authentication system should follow:

1. Constant-Time Operations
   Always ensure security-critical operations take the same time regardless of input. Use dummy operations when needed.

2. Never Trust Client Headers Directly
   Always validate proxy headers through your framework's built-in mechanisms (like Express's trust proxy).

3. Use Atomic Database Operations
   For operations that check and modify state (like OTP verification), use atomic database operations to prevent race conditions.

4. Distributed Rate Limiting
   Use Redis or similar for rate limiting in distributed systems.
   Always have a fallback mechanism.

5. Comprehensive Testing
   Write security-focused tests that specifically check for timing attacks, race conditions, and edge cases.

Testing Your Authentication System
We implemented comprehensive security tests to ensure these vulnerabilities stay fixed:

describe('Timing Attack Protection', () => {
  it('should have constant-time execution for non-existent users', async () => {
    const time1 = await measureLoginTime('[e-mail]');
    const time2 = await measureLoginTime('[e-mail]');

    // Times should be similar (within 50ms tolerance)
    expect(Math.abs(time1 - time2)).toBeLessThan(50);
  });
});

Key test categories:

Timing attack protection
Rate limiting effectiveness
Race condition prevention
Input validation
Conclusion: Building Secure Authentication
Authentication security is a continuous process.
The vulnerabilities we discovered are subtle but critical, and they're more common than you might think. By understanding these issues and implementing proper fixes, you can significantly improve your application's security posture.

Key Takeaways
Timing attacks are real - Always use constant-time operations for security-critical code
Never trust client headers - Use framework mechanisms for proxy validation
Race conditions matter - Use atomic database operations for state changes
Test security explicitly - Don't just test happy paths; test attack scenarios
Distributed systems need distributed rate limiting - In-memory limits don't scale
About Rugi Auth
While working on these security improvements, I was building Rugi Auth—a centralized authentication service designed with security as a first-class concern. It includes:

✅ RS256 JWT signing with RSA keys
✅ Argon2id password hashing (memory-hard, timing-attack resistant)
✅ Redis-backed distributed rate limiting with automatic fallback
✅ Comprehensive security protections against timing attacks, IP spoofing, and race conditions
✅ Extensive test coverage including security-focused tests
✅ Multi-app role management for complex authorization needs
If you're building authentication for your applications, I'd love for you to check it out. You can get started with:

npx rugi-auth init my-auth-server
The project is open-source, and all the security improvements discussed in this article are implemented and tested. You can find it on GitHub and install it via npm.

Resources
OWASP Authentication Cheat Sheet
Timing Attack Prevention
Express Trust Proxy Documentation
Redis Rate Limiting Best Practices

Have you encountered these vulnerabilities in your projects? What security measures do you implement in your authentication systems? Share your thoughts in the comments below!