# Observable Timing Discrepancy (CWE-208)

Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product.

- Prevalence: Medium 1 language covered
- Impact: Medium Review recommended
- Prevention: Documented 1 fix examples

**OWASP:** Cryptographic Failures (A02:2021-Cryptographic Failures) - #2

## Description

In authentication scenarios, timing attacks can be used to determine if a username is valid by measuring response times. Similar attacks can be used against cryptographic operations.

## Prevention

Prevention strategies for Observable Timing Discrepancy based on 1 Shoulder detection rules.

### Node.js

Use crypto.timingSafeEqual() for comparing secrets, signatures, and hashes

## Warning Signs

- [MEDIUM] Direct string comparison of cryptographic value (signature/HMAC/hash) is vulnerable to timing attacks
- [MEDIUM] direct string comparison of cryptographic values (HMAC, signatures, hashes)
where timing attacks are

## Consequences

- Read Application Data
- Bypass Protection Mechanism

## Mitigations

- Use constant-time comparison functions for security-sensitive comparisons
- Add random delays to mask timing differences
- Use the same code path regardless of success or failure

## Detection

- Total rules: 1
- Languages: javascript, typescript

## Rules by Language

### Javascript (1 rules)

- **Timing Attack via Direct Cryptographic Comparison** [MEDIUM]: Detects direct string comparison of cryptographic values (HMAC, signatures, hashes)
where timing attacks are practically exploitable.

This rule focuses on HIGH-RISK patterns where timing attacks have been demonstrated
in real-world attacks:
- HMAC/signature verification (webhook signatures, JWT manual verification)
- Hash comparison (when verifying pre-computed hashes)

NOT flagged (low practical risk over network):
- Password comparison: Network jitter (ms) overwhelms timing differences (ns).
  The real fix is using bcrypt/argon2 which handles this automatically.
- General token comparison: Usually better addressed by secure token generation
  and proper session management.

Timing attacks on cryptographic comparisons are practical because:
1. Attacker controls the input format exactly
2. Signatures have known structure (hex/base64)
3. Can be automated with statistical analysis
4. Have been used in real attacks (GitHub, Slack webhook bypasses)
  - Remediation: Use crypto.timingSafeEqual() for comparing signatures, HMACs, and hashes.

### Typescript (1 rules)

- **Timing Attack via Direct Cryptographic Comparison** [MEDIUM]: Detects direct string comparison of cryptographic values (HMAC, signatures, hashes)
where timing attacks are practically exploitable.

This rule focuses on HIGH-RISK patterns where timing attacks have been demonstrated
in real-world attacks:
- HMAC/signature verification (webhook signatures, JWT manual verification)
- Hash comparison (when verifying pre-computed hashes)

NOT flagged (low practical risk over network):
- Password comparison: Network jitter (ms) overwhelms timing differences (ns).
  The real fix is using bcrypt/argon2 which handles this automatically.
- General token comparison: Usually better addressed by secure token generation
  and proper session management.

Timing attacks on cryptographic comparisons are practical because:
1. Attacker controls the input format exactly
2. Signatures have known structure (hex/base64)
3. Can be automated with statistical analysis
4. Have been used in real attacks (GitHub, Slack webhook bypasses)
  - Remediation: Use crypto.timingSafeEqual() for comparing signatures, HMACs, and hashes.