🛡️ Sentinel: [CRITICAL] Fix user enumeration timing attack

.jules/sentinel.md

@@ -0,0 +1,4 @@
+## 2025-05-18 - [Fix bcrypt timing attack vulnerability in user enumeration]
+**Vulnerability:** A timing attack vulnerability allowed attackers to determine if an email address exists in the system by measuring the response time of the login endpoint. The code used an invalid bcrypt hash (`$2a$12$dummyhashdummyhashdummyhashdummyhashdummyhashdummyha`) for the "user not found" case.
+**Learning:** `bcryptjs.compare` checks if the format of the hash is valid before doing the expensive hashing computation. If the hash format is invalid (e.g., incorrect base64 characters or length), it returns immediately (e.g. 0.04ms). A valid hashing operation takes several hundred milliseconds (e.g. ~400-800ms depending on CPU and cost factor). The drastic difference in response time exposed whether a user existed or not.
+**Prevention:** Always use a valid, pre-computed bcrypt hash of a random string with the same work factor as your system when simulating password verification to prevent timing attacks.

back/package.json

@@ -45,15 +45,15 @@
     "bullmq": "^5.72.0",
     "class-transformer": "^0.5.1",
     "class-validator": "^0.14.2",
+    "cookie-parser": "^1.4.7",
     "dotenv": "^17.2.3",
     "helmet": "^8.1.0",
     "mercadopago": "^2.12.0",
     "nodemailer": "^8.0.4",
     "pg": "^8.20.0",
     "reflect-metadata": "^0.2.2",
     "rxjs": "^7.8.1",
-    "speakeasy": "^2.0.0",
-    "cookie-parser": "^1.4.7"
+    "speakeasy": "^2.0.0"
   },
   "devDependencies": {
     "@eslint/js": "^9.19.0",
@@ -64,8 +64,8 @@
     "@types/jest": "^30.0.0",
     "@types/node": "^20.17.19",
     "@types/nodemailer": "^7.0.11",
+    "@types/pg": "^8.20.0",
     "@types/speakeasy": "^2.0.10",
-
     "eslint": "^9.18.0",
     "eslint-config-prettier": "^10.0.1",
     "eslint-plugin-prettier": "^5.2.3",