Protecting Against Brute Force & Credential Stuffing

Introduction to Advanced Authentication Attacks

Welcome to our lesson on protecting against brute force and credential stuffing attacks! In our previous lessons, we've built a solid foundation for secure authentication by implementing password hashing, rate limiting, and role-based access control (RBAC). Today, we'll take our security measures a step further by detecting and responding to suspicious login activities. While rate limiting helps prevent rapid-fire login attempts, sophisticated attackers can still bypass these measures by distributing their attempts across multiple IP addresses or by slowing down their attack patterns. This is where advanced detection mechanisms become crucial. Brute force attacks involve systematically trying every possible password combination until finding the correct one. Credential stuffing, on the other hand, uses stolen username/password pairs from other breached websites, exploiting the fact that many users reuse credentials across multiple services. According to recent security reports, credential stuffing accounts for over 80% of login attempts on many popular websites, making it one of the most common attack vectors today. Our existing rate limiting implementation provides a good first line of defense, but it's not enough on its own. Today, we'll implement a system that can detect suspicious login patterns by monitoring changes in user behavior, such as logins from new locations or devices.

Detecting Suspicious Login Patterns

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Implementing the Detection Middleware

Now that we understand how our detection middleware works, let's see how to integrate it into our Express application. We'll need to add the middleware to our application's middleware chain, ensuring it runs for every request.

Here's how we can integrate the suspicious login detection middleware into our Express application:

TypeScript

import express from 'express';
import session from 'express-session';
import { sequelize } from './models';
import { detectSuspiciousLogin } from './middleware/detectSuspiciousLogin';
import { secureSessionAfterSuspiciousActivity } from './middleware/secureSessionAfterSuspiciousActivity';

const app = express();
app.use(express.json());

app.use(session({
  secret: 'your-strong-secret-key',
  resave: false,
  saveUninitialized: false,
  cookie: { secure: false } // set to true in production with HTTPS
}));

// Middleware for suspicious login detection
app.use(detectSuspiciousLogin);

// Middleware for session security after suspicious login detection
app.use(secureSessionAfterSuspiciousActivity);

sequelize.sync().then(() => {
  app.listen(3000, () => {
    console.log('Server is running on port 3000');
  });
});

import express from 'express';
import session from 'express-session';
import { sequelize } from './models';
import { detectSuspiciousLogin } from './middleware/detectSuspiciousLogin';
import { secureSessionAfterSuspiciousActivity } from './middleware/secureSessionAfterSuspiciousActivity';

const app = express();
app.use(express.json());

app.use(session({
  secret: 'your-strong-secret-key',
  resave: false,
  saveUninitialized: false,
  cookie: { secure: false } // set to true in production with HTTPS
}));

// Middleware for suspicious login detection
app.use(detectSuspiciousLogin);

// Middleware for session security after suspicious login detection
app.use(secureSessionAfterSuspiciousActivity);

sequelize.sync().then(() => {
  app.listen(3000, () => {
    console.log('Server is running on port 3000');
  });
});

In this setup, we first configure the Express session middleware, which is essential for storing and retrieving session data. Then, we add our detectSuspiciousLogin middleware to the chain, followed by another middleware called secureSessionAfterSuspiciousActivity, which we'll implement shortly.

It's important to note that the order of middleware matters in Express. Our detection middleware must run after the session middleware (since it relies on session data) but before any route handlers that might need to know about suspicious login attempts.

This implementation complements our existing rate limiting solution by adding another layer of security. While rate limiting prevents rapid-fire login attempts, our new detection mechanism can identify more subtle attacks that might slip through the rate limiting defense.

Responding to Suspicious Activities

Detecting suspicious login attempts is only half the battle. We also need to implement appropriate responses to protect user accounts when suspicious activities are detected.

Let's implement a middleware function that takes action when a suspicious login is detected:

TypeScript

import { Request, Response, NextFunction } from 'express';

export const secureSessionAfterSuspiciousActivity = (req: Request, res: Response, next: NextFunction) => {
  if (req.session.suspiciousLogin) {
    req.session.destroy((err) => {
      if (err) {
        console.error('Error destroying session after suspicious activity:', err);
        return res.status(500).json({ error: 'Internal server error' });
      }
      return res.status(403).json({ error: 'Suspicious activity detected. Session terminated. Please log in again.' });
    });
  } else {
    next();
  }
};

import { Request, Response, NextFunction } from 'express';

export const secureSessionAfterSuspiciousActivity = (req: Request, res: Response, next: NextFunction) => {
  if (req.session.suspiciousLogin) {
    req.session.destroy((err) => {
      if (err) {
        console.error('Error destroying session after suspicious activity:', err);
        return res.status(500).json({ error: 'Internal server error' });
      }
      return res.status(403).json({ error: 'Suspicious activity detected. Session terminated. Please log in again.' });
    });
  } else {
    next();
  }
};

This middleware checks if the suspiciousLogin flag is set in the session. If it is, it destroys the session and returns a 403 Forbidden response with an error message. If there's no suspicious activity detected, it simply passes control to the next middleware.

Destroying the session is a strong response that forces the user to log in again, which can be effective in stopping an attack in progress. However, it might also inconvenience legitimate users who are logging in from a new device or location.

In a production environment, you might want to implement a more nuanced approach, such as:

Requiring additional verification (e.g., email confirmation or two-factor authentication) instead of immediately terminating the session
Implementing a progressive response system that escalates based on the number and severity of suspicious activities
Notifying the user about the suspicious login attempt via email or other channels
Temporarily restricting certain high-risk actions (e.g., changing passwords or making payments) without completely blocking access

The right approach depends on your application's security requirements and user experience considerations. For high-security applications, you might prioritize security over convenience, while for consumer applications, you might need to strike a more balanced approach.

Introduction to Advanced Authentication Attacks

Detecting Suspicious Login Patterns

Join the 1M+ learners on CodeSignal

Implementing the Detection Middleware

Security Logging Implementation

Responding to Suspicious Activities

Summary and Practice Preparation