[Security] Weak Password Hashing (Legacy SHA-256) in `tests/test_security.py`

[pranav-cholleti]

🔒 Security Vulnerability: Weak Password Hashing (Legacy SHA-256)

Severity: 🟠 High
CWE: CWE-916
File: tests/test_security.py
Line: 114
Pattern: DEEP-001

Description

The application module (app_module) supports the verification of legacy password hashes generated using unsalted SHA-256 (as demonstrated by the test at line 114). While the check_lock function in app_module attempts to migrate these weak hashes to a stronger PBKDF2-HMAC-SHA256 upon successful verification, the initial storage and comparison of unsalted SHA-256 hashes poses a significant security risk. If an attacker gains access to the locks.json file containing these legacy hashes before they are migrated, they can easily perform offline brute-force attacks or use rainbow tables to recover the original passwords due to the lack of salt and insufficient computational cost.

Vulnerable Code

111:     # Pre-populate with legacy SHA-256 lock
112:     rel_path = "category/script.sh"
113:     password = "legacy_pwd"
114:     legacy_hash = hashlib.sha256(password.encode('utf-8')).hexdigest()
115:     
116:     locks_file.write_text(json.dumps({rel_path: legacy_hash}))
117:     

Suggested Fix

All legacy SHA-256 hashes should be migrated to a strong KDF like PBKDF2-HMAC-SHA256 with a random salt and sufficient iterations (e.g., app_module.PBKDF2_ITERATIONS) as soon as possible. Implement a one-time, application-wide migration on startup or a background task to upgrade all existing legacy hashes in locks.json without requiring user interaction. Ensure that new locks are never created using weak algorithms like unsalted SHA-256. The check_lock function should prioritize migrating these hashes immediately rather than waiting for user interaction. If immediate migration for all users is not feasible, consider prompting users with legacy hashes to update their passwords.

AI Analysis

The application module (app_module) supports the verification of legacy password hashes generated using unsalted SHA-256 (as demonstrated by the test at line 114). While the check_lock function in app_module attempts to migrate these weak hashes to a stronger PBKDF2-HMAC-SHA256 upon successful verification, the initial storage and comparison of unsalted SHA-256 hashes poses a significant security risk. If an attacker gains access to the locks.json file containing these legacy hashes before they are migrated, they can easily perform offline brute-force attacks or use rainbow tables to recover the original passwords due to the lack of salt and insufficient computational cost.

---

Found by IssueRes Security Scanner