Security vulnerabilities and automated fixes for pbkdf2 issues
6 posts found
A critical vulnerability in `libs/wgs/pbkdf2.js` used only 1 iteration for PBKDF2 password hashing, making passwords trivially crackable. The fix increases iterations to 600,000, aligning with OWASP 2023 recommendations and preventing GPU-accelerated brute-force attacks.
The Frida Android server used PBKDF2WithHmacSHA1And8BIT with only 128 iterations to derive secret keys for device attestation. This critically weak configuration made password brute-forcing trivial, allowing attackers who obtained the derived key to recover the original password in seconds. The fix upgraded to PBKDF2WithHmacSHA256 with 600,000 iterations, meeting modern cryptographic standards.
A critical vulnerability (CVE-2025-6545) in pbkdf2 version 3.1.2 caused the library to silently return predictable key material instead of cryptographically secure keys. This Node.js dependency issue was discovered in the website/package-lock.json file and fixed by upgrading to pbkdf2 3.1.3, preventing potential authentication bypass and data exposure in production systems.
A medium-severity vulnerability was discovered where OAuth tokens and API keys were stored in plaintext on the local filesystem without encryption. Despite having PBKDF2 cryptographic capabilities available in the application's dependencies, these sensitive credentials were written directly to disk, exposing users to potential credential theft and unauthorized account access.
A medium-severity vulnerability was discovered where OAuth tokens and API keys were being stored in plaintext on the local filesystem without any encryption. Despite having PBKDF2 cryptographic capabilities available in the project dependencies, the authentication module was writing sensitive credentials directly to disk, leaving them vulnerable to unauthorized access. This fix addresses a common but dangerous security oversight that could compromise user accounts and API access.
A medium-severity vulnerability was discovered where OAuth tokens and API keys were being stored in plaintext on the local filesystem without any encryption. Despite having PBKDF2 cryptographic capabilities available in the application's dependencies, credentials were written directly to disk, exposing users to potential token theft and unauthorized account access.