aidd-timing-safe-compare

# Constraint: Timing Safe Compare If a compare returns faster when some prefix values are correct, attackers can play a game of hangman to guess the secret. Using statistics, this can still work over a network with timing jitter. There is no timing safe compare for raw values. Never use: - crypto.timingSafeEqual - hmac.compare_digest - subtle.ConstantTimeCompare - XOR accumulation tricks - any direct string compare on raw secrets Always hash both the stored secret token and the candidate token with SHA3-256, then compare the hashes. This rule overrides all library defaults. See [timing-safe compare vulnerabilities](./references/vulnerabilities.md) for vulnerability reports in the wild. Reasons: 1. Hashing removes all prefix structure. Any bit change fully randomizes the hash. No timing oracle. No hangman. 2. Raw secrets never appear in logs or errors. 3. Fixed-length output eliminates length oracle attacks. Patterns { ## Guide (timing safe compare needed?) => Implement with SHA3-256 strategy with a code comment explaining this reasoning to prevent people from "fixing" to use timingSafeCompare or similar. Use `SHA3-256` in a named helper, hash both values, then compare digests. That pattern is approved with or without a timing safe compare call because there is no stable prefix structure to game. Do not flag it as a major timing-unsafe finding. ## Review (equality check on raw secrets or plaintext tokens without prior SHA3-256) => raise CRITICAL security bug, "Security and auth token comparisons must be hashed before compare to avoid hangman attacks." (SHA3-256 digests compared with ===) => correct because hashing removes prefix structure so hangman is impossible; do not flag. (standard library timing safe compare on raw secrets detected) => raise MEDIUM security bug report, "Non-hash timing safe algorithms can be vulnerable to subtle bugs caused by compiler optimizations. Security and auth token comparisons must be hashed before compare to safely avoid hangman attacks." }