Bleichenbacher Attack in Express with Basic Auth

A Bleichenbacher Attack is a practical adaptive chosen-ciphertext attack against cryptosystems that use PKCS#1 v1.5 padding during decryption. In Express, when authentication is handled with HTTP Basic Auth and the server-side implementation performs decryption or signature verification using a library that reveals timing differences or error messages, the combination can expose a side-channel vulnerability. Basic Auth transmits credentials as a base64-encoded string; while base64 itself is not encryption, developers sometimes store or compare secrets in a way that involves cryptographic operations (e.g., decrypting a token or verifying a signature) where PKCS#1 v1.5 padding is used.

Express does not provide built-in decryption for Basic Auth credentials; the onus is on the developer to handle secrets safely. If a server uses an RSA-based decryption or verification routine (for example, to validate a signed session token or to unwrap an encrypted credential) and relies on error messages like “invalid padding” or “decryption error” to distinguish between malformed ciphertexts and incorrect padding, the timing of these responses can leak information. An attacker can craft many ciphertexts and measure response times to gradually recover the plaintext or the padding validity, effectively bypassing the intended confidentiality or integrity guarantees.

In the context of an Express API scanned by middleBrick, this manifests as a finding in the Input Validation and Encryption checks. The scan does not probe internal cryptographic libraries directly but tests observable behaviors: inconsistent error messages, timing differences in authentication responses, and endpoints that accept encrypted or signed payloads without constant-time verification. If an endpoint accepts a Basic Auth credential that is later decrypted with a vulnerable PKCS#1 v1.5 routine, middleBrick may flag the Encryption check and surface related findings under Data Exposure or Authentication. Remediation focuses on replacing error-oracle behavior with constant-time comparison or decryption, avoiding decryption of user-supplied data where possible, and ensuring that authentication failures return uniform responses and status codes.

To mitigate risks when using HTTP Basic Auth in Express, avoid performing cryptographic operations on user-supplied credentials and ensure authentication failures do not leak information. Always parse credentials safely, use constant-time comparison for secrets when necessary, and enforce transport security.

Safe Basic Auth parsing and uniform responses

Do not attempt to decrypt or validate embedded secrets from the Basic Auth token in a way that produces distinct errors. Instead, validate credentials against a constant-time comparison and return the same generic response for any authentication failure.

const auth = require('basic-auth');
const crypto = require('crypto');

// Example secret stored server-side (e.g., a hashed API key or password)
const SERVER_SECRET = 'superSecretValue123';

function authenticate(req, res, next) {
  const user = auth(req);
  if (!user || !user.name || !user.pass) {
    res.set('WWW-Authenticate', 'Basic realm="example"');
    return res.status(401).json({ error: 'Authentication required' });
  }

  // Use constant-time comparison to avoid timing leaks
  const isValid = crypto.timingSafeEqual(
    Buffer.from(user.pass),
    Buffer.from(SERVER_SECRET)
  );

  if (!isValid) {
    res.set('WWW-Authenticate', 'Basic realm="example"');
    return res.status(401).json({ error: 'Authentication required' });
  }

  next();
}

// Apply to routes as needed
app.get('/api/secure', authenticate, (req, res) => {
  res.json({ message: 'Authenticated' });
});

Avoid decryption in authentication flow

If you must work with encrypted or signed tokens, perform decryption or verification in a secure context and map outcomes to uniform outcomes. Do not let padding errors or decryption exceptions propagate to the client.

const jwt = require('jsonwebtoken');

app.get('/api/token', (req, res, next) => {
  const token = req.headers.authorization && req.headers.authorization.split(' ')[1];
  if (!token) {
    return res.status(401).json({ error: 'Authorization token missing' });
  }

  try {
    // Verify using a strong algorithm and constant-time-safe library usage
    const decoded = jwt.verify(token, process.env.JWT_PUBLIC_KEY, { algorithms: ['RS256'] });
    req.user = decoded;
    next();
  } catch (err) {
    // Always return a generic failure to prevent oracle attacks
    res.status(401).json({ error: 'Invalid token' });
  }
});

Transport and headers

Always serve endpoints over HTTPS to protect credentials in transit. Use security headers to reduce information leakage and enforce strict CORS policies.

app.use((req, res, next) => {
  res.set({
    'Strict-Transport-Security': 'max-age=63072000; includeSubDomains; preload',
    'X-Content-Type-Options': 'nosniff',
    'X-Frame-Options': 'DENY'
  });
  next();
});