Timing Attack in Feathersjs with Jwt Tokens

A timing attack in a FeathersJS application that uses JWT tokens can occur during token validation, particularly when comparing signatures or handling invalid tokens. FeathersJS typically relies on libraries such as jsonwebtoken to verify JWTs. If the verification or subsequent logic does not use constant-time operations, an attacker can infer information about the token or internal state based on response timing differences.

Consider a FeathersJS service where the JWT secret is not handled with constant-time comparison. When an invalid token is presented, the server might perform early exits or string comparisons that take different amounts of time depending on how many characters match. For example, a naive string comparison of the signature can short-circuit on the first mismatching character, allowing an attacker to iteratively guess the signature or parts of the token by measuring response times. This is especially relevant when the token is used for authentication or authorization decisions, as the server may leak whether a given user ID or role encoded in the token is valid based on timing.

Additionally, FeathersJS hooks that process JWTs might introduce timing variability. If a hook performs database lookups or conditional checks that depend on token validity in a non-constant manner, an attacker can correlate timing with the correctness of the token. For instance, if a token with a valid structure but invalid signature leads to a different code path than a completely malformed token, the timing difference can be measured. This can expose whether a token is structurally valid, even if cryptographically invalid, aiding in an attacker's ability to forge tokens or escalate privileges.

Real-world attack patterns related to this include OWASP API Top 10 A07:2021 — Identification and Authentication Failures, where insufficient protection against timing attacks leads to token compromise. In the context of PCI-DSS and SOC2, such vulnerabilities can undermine authentication controls. A practical example is an attacker sending tokens with slightly modified signatures and observing mill-level differences in response times, gradually reconstructing the expected signature or secret over many requests.

To mitigate timing attacks when using JWT tokens in FeathersJS, ensure that all cryptographic comparisons and token handling routines are performed in constant time. Below are concrete code examples demonstrating secure practices.

1. Use constant-time token verification

When verifying JWT signatures, rely on the built-in constant-time verification provided by the jsonwebtoken library. Do not perform additional string comparisons on token payloads or signatures manually.

const jwt = require('jsonwebtoken');
const SECRET = process.env.JWT_SECRET;

// ✅ Secure: Use the library's verify method which handles signature comparison safely
function verifyToken(token) {
  try {
    const decoded = jwt.verify(token, SECRET);
    return decoded; // Safe, constant-time verification
  } catch (err) {
    // Handle invalid tokens uniformly without leaking timing details
    throw new Error('Invalid token');
  }
}

// In a FeathersJS service hook
function authenticateHook(context) {
  const { accessToken } = context.params.query;
  if (!accessToken) {
    throw new Error('No token provided');
  }
  context.params.user = verifyToken(accessToken);
  return context;
}

2. Avoid branching on token validity

Ensure that the code path for valid and invalid tokens takes roughly the same amount of time. Do not early-return or throw errors that could be distinguished by timing.

// ✅ Secure: Uniform handling regardless of token validity
function safeTokenCheck(req, res) {
  const token = req.headers.authorization?.split(' ')[1];
  let isValid = false;
  let decoded = null;

  if (token) {
    try {
      decoded = jwt.verify(token, SECRET);
      isValid = true;
    } catch (err) {
      // Intentionally do nothing — keep timing consistent
    }
  }

  // Perform the same operations regardless of validity
  const result = computeResponse(isValid, decoded);
  res.json(result);
}

function computeResponse(isValid, user) {
  // Simulate work to mask timing differences
  const start = Date.now();
  while (Date.now() - start < 5) { }

  return isValid ? { user } : { error: 'Unauthorized' };
}

3. Use constant-time string comparison for custom logic

If you must compare strings derived from token claims (e.g., comparing a nonce or a custom claim), use a constant-time comparison function.

// ✅ Secure: Constant-time comparison for strings
function constantTimeCompare(a, b) {
  if (a.length !== b.length) {
    return false;
  }
  let result = 0;
  for (let i = 0; i < a.length; i++) {
    result |= a.charCodeAt(i) ^ b.charCodeAt(i);
  }
  return result === 0;
}

// Example usage within a FeathersJS hook
function checkCustomClaim(context) {
  const expected = 'expected-nonce-value';
  const actual = context.params.user?.customNonce;
  if (!constantTimeCompare(expected, actual)) {
    throw new Error('Invalid claim');
  }
  return context;
}

4. Enforce secure token practices in FeathersJS configuration

Configure FeathersJS to use secure JWT practices, such as strong algorithms and short expiration times, reducing the window for timing-based attacks.

const authentication = {
  secret: process.env.JWT_SECRET,
  strategy: 'jwt',
  jwt: {
    algorithms: ['HS256'],
    expiresIn: '15m' // Short-lived tokens reduce exposure
  }
};

module.exports = {
  authentication
};