🛡️ Sentinel: [HIGH] Harden timing-safe comparison in safeEqual#54
🛡️ Sentinel: [HIGH] Harden timing-safe comparison in safeEqual#54SuvenSeo wants to merge 1 commit into
Conversation
Modified safeEqual to hash inputs with SHA-256 before comparison to prevent length-based timing attacks. Added .jules/sentinel.md security journal entry. Co-authored-by: SuvenSeo <263689617+SuvenSeo@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Pull request overview
This PR hardens the safeEqual helper used across the Next.js backend for comparing sensitive secrets (API tokens, cron secrets, Telegram webhook secret, and dashboard password/session values) by removing a length-dependent early return and ensuring comparisons are performed over fixed-size inputs.
Changes:
- Updated
safeEqualto hash both inputs with SHA-256 and compare the resulting fixed-length digests usingtimingSafeEqual. - Added a Sentinel security journal entry documenting the issue and the mitigation approach.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
frontend/src/lib/middleware/auth.js |
Reworks safeEqual to avoid length-based timing differences by comparing SHA-256 digests with timingSafeEqual. |
.jules/sentinel.md |
Documents the discovered issue and the mitigation strategy in a security journal entry. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| const aHash = createHash('sha256').update(String(a)).digest(); | ||
| const bHash = createHash('sha256').update(String(b)).digest(); | ||
| return timingSafeEqual(aHash, bHash); |
🚨 Severity: HIGH
💡 Vulnerability: The
safeEqualutility used for sensitive token and password comparison was vulnerable to length-based timing attacks. It performed a length check (left.length === right.length) before callingtimingSafeEqual.🎯 Impact: An attacker could determine the exact length of secret tokens or passwords by measuring small timing differences in response times, significantly reducing the search space for brute-force attacks.
🔧 Fix: Modified
safeEqualto hash both inputs using SHA-256 before comparison. Since SHA-256 outputs are always 32 bytes,timingSafeEqualalways compares buffers of equal length, masking the original input length.✅ Verification: Ran
npm test --prefix frontend. All 34 tests passed, including authentication and Telegram webhook verification. Documented in.jules/sentinel.md.PR created automatically by Jules for task 12240958626763914271 started by @SuvenSeo