Skip to content

fix(auth): mitigate login timing side-channel via dummy bcrypt hash (#38) - #71

Open
ghzhost wants to merge 1 commit into
StellarSend:mainfrom
ghzhost:fix/login-bcrypt-timing-attack-38
Open

fix(auth): mitigate login timing side-channel via dummy bcrypt hash (#38)#71
ghzhost wants to merge 1 commit into
StellarSend:mainfrom
ghzhost:fix/login-bcrypt-timing-attack-38

Conversation

@ghzhost

@ghzhost ghzhost commented Sep 2, 2026

Copy link
Copy Markdown

Summary

Addresses #38 by closing the observable timing discrepancy (CWE-208) in src/routes/auth.rs::login.

Changes

  • Introduced a valid precomputed bcrypt hash (DUMMY_BCRYPT_HASH with standard cost factor 12) for nonexistent / inactive accounts.
  • login now always runs bcrypt::verify before checking user presence, equalizing execution time between existing and nonexistent email lookups.
  • Preserves identical error responses (AppError::InvalidCredentials -> 401 INVALID_CREDENTIALS).
  • Added unit test asserting DUMMY_BCRYPT_HASH parses and verifies safely.

Closes #38.

…tellarSend#38)

- Always execute bcrypt::verify even if user email is not found or account is inactive
- Uses a valid cost-12 dummy hash to equalize latency across existing and non-existing accounts
- Returns identical 401 INVALID_CREDENTIALS error response
- Closes StellarSend#38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Login has a bcrypt timing side-channel that lets attackers enumerate registered emails

1 participant