0x55aa
← Back to Blog

Timing Attacks: Your String Comparison Is Leaking Secrets One Nanosecond at a Time ⏱️

•6 min read
"cybersecurity""web-security""security""authentication""side-channel"

Timing Attacks: Your String Comparison Is Leaking Secrets One Nanosecond at a Time ⏱️

Imagine a safe cracker — not the Hollywood kind with a stethoscope pressed against a vault — but the real kind, who just listens for tiny variations in resistance as they turn the dial.

Each click tells them: you're getting warmer.

Your web application does the same thing. Every time you compare two strings the "normal" way, you're potentially handing attackers a stethoscope.

Welcome to timing attacks. The vulnerability that makes security engineers lose sleep and makes everyone else say "wait... WHAT?"

What Even Is a Timing Attack? 🕵️

Here's the deal. When a computer compares two strings character by character, it stops as soon as it finds a mismatch.

"admin_token_xyz"  ← correct token
"admin_token_abc"  ← attacker's guess
             ↑ stops here

A wrong guess at position 3 returns faster than a wrong guess at position 13.

Attackers can measure these tiny time differences — we're talking nanoseconds — across thousands of requests to deduce what the real value looks like. Character by character. Like cracking a combination lock by feel.

In my experience building production systems with high-value API tokens and payment webhooks, this is the kind of attack that doesn't show up in your error logs. It's completely invisible. No stack traces, no 500 errors. Just a patient attacker with a script, a statistics library, and time.

The Code That's Quietly Betraying You 🔓

This looks perfectly fine. I've written this myself, I'm not proud of it:

// ❌ VULNERABLE - timing-safe it is NOT
if ($request->api_key === config('app.api_key')) {
    // grant access
}

// ❌ Also vulnerable
if (strcmp($userToken, $storedToken) === 0) {
    // "I used a real comparison function, I'm so smart"
}

// ❌ Even this is vulnerable
if ($webhookSignature == $expectedSignature) {
    // "I learned from the docs!" -- the docs lied
}

All of these bail out early when they hit the first mismatched character. You're leaking timing information with every single request.

Real-World Targets: It's Not Just Passwords 🎯

Pro Tip: Password logins are mostly not vulnerable to this because you're comparing hashes (which are fixed-length and cached), and good frameworks add enough noise to drown out timing signals.

Where it actually matters:

1. API Keys & Tokens

// Every Laravel dev has written this
if ($request->header('X-API-Key') === $user->api_key) { ... }

2. Webhook Signatures

// Stripe, GitHub, every payment processor sends these
$signature = hash_hmac('sha256', $payload, $secret);
if ($signature === $request->header('X-Signature')) { ... }

3. Password Reset / Magic Link Tokens

$token = PasswordReset::where('email', $email)->first()->token;
if ($token === $request->token) { ... }

These are all leaking. The attacker doesn't need to brute-force the entire token — they just figure out one character at a time. For a 32-character hex token, that's 32 × 16 = 512 attempts instead of 16^32.

Math is terrifying.

The Fix: Constant-Time Comparison 🛡️

The solution is elegant: use a comparison function that always takes the same amount of time, regardless of where the strings diverge.

PHP — use hash_equals():

// ✅ SAFE - constant time comparison
if (hash_equals($expectedSignature, $actualSignature)) {
    // process webhook
}

// ✅ SAFE - Laravel's built-in for tokens
if (hash_equals($storedToken, $request->token)) {
    // valid token
}

Node.js — use crypto.timingSafeEqual():

const crypto = require('crypto');

// ✅ SAFE
const expected = Buffer.from(expectedSignature, 'hex');
const actual = Buffer.from(actualSignature, 'hex');

// Must be same length first! (use hmac which guarantees fixed length)
if (expected.length === actual.length &&
    crypto.timingSafeEqual(expected, actual)) {
    // valid signature
}

How it works: hash_equals() and timingSafeEqual() always examine every character of both strings, no early exits, no "ah close enough" shortcuts. The function runs in constant time regardless of how many characters match.

In Security Communities, We See This Pattern Everywhere 🔍

As someone passionate about security and active in communities like YAS and InitCrew, the timing attack conversation comes up constantly when reviewing webhook implementations. And almost every time, someone's doing this:

// Someone's production Stripe webhook handler, probably right now
if ($_POST['signature'] === getenv('STRIPE_SECRET')) {
    // fulfill the order
}

The attacker doesn't need your Stripe secret. They just need to send millions of requests with varying signatures, measure the response times, and statistically reconstruct it. Modern timing attack tools can do this remotely — network jitter and all — because statistics smooths out the noise.

During one of our security review sessions, we found a payment webhook handler in a Laravel app that was comparing HMAC signatures with ==. The fix was one line. The potential damage was... not one line.

Real Talk: "But Network Latency Ruins the Timing Signal, Right?" 💬

This is the most common pushback I hear. And yes, network jitter does add noise. But:

  1. Statistical analysis over many requests smooths it out. Attackers send tens of thousands of requests and look at averages.
  2. Cloud functions are fast. Modern serverless environments have millisecond response times, which makes nanosecond differences more detectable, not less.
  3. Local network attacks (same datacenter, same VPC) have almost zero jitter.
  4. Automated tools like timing_attack and thetimingattack exist specifically to exploit this remotely.

Don't bet your security on network noise. Just use the constant-time function. It's one function call.

Your Timing Attack Checklist 📋

Grep your codebase for these patterns right now:

# Find potential timing-unsafe comparisons with secrets
grep -rn "=== \$request" app/
grep -rn "== \$token" app/
grep -rn "strcmp(" app/

Then ask: is either side of this comparison a secret value? If yes, use hash_equals().

Safe:

  • All webhook signature verifications use hash_equals()
  • API key comparisons use hash_equals()
  • Password reset token checks use hash_equals()
  • HMAC signature verification uses constant-time comparison
  • Magic link tokens use hash_equals()

Bonus points:

  • Tokens are long enough that even timing-optimized brute force isn't feasible
  • Rate limiting on all token validation endpoints (belt AND suspenders)
  • Token expiry so stolen tokens have a short shelf life

The Beautiful Irony 🎭

You can do everything right — bcrypt your passwords, use HTTPS, rotate your secrets — and then accidentally expose your API key through the timing of a === comparison.

Security is humbling like that. It's not one big mistake; it's a thousand tiny ones.

In my experience building serverless e-commerce backends on AWS, the attacks that kept me up at night weren't the flashy ones. They were the subtle, invisible ones. Timing attacks live in that category.

The good news: the fix is genuinely trivial. One function. Takes 30 seconds. Go do it.

Found a timing vulnerability in your codebase? Come talk security on LinkedIn — I'm always up for a good "what were we thinking" story.

Want the deep dive? Check out the original timing attack paper by Paul Kocher — it's from 1996 and security engineers are still fixing the fallout.

Stay paranoid, stay safe. 🔐

← Back to all posts