Weak PBKDF2 parameters for password-encrypted private-key export in jose

Overview

Use of Password Hash With Insufficient Computational Effort in the jose library allows an attacker who obtains a password-encrypted private-key export to recover the private key through an offline password-cracking attack.

When jose exports a password-encrypted private key with jose_jwk:to_der/2 (JOSE.JWK.to_der/2), the jose_jwk_der:to_binary/3 function in src/jwk/jose_jwk_der.erl serializes the key as a PKCS#8 EncryptedPrivateKeyInfo using the PBES2 scheme with hardcoded key-derivation parameters: PBKDF2-HMAC-SHA256 with an iteration count of 2048 and an 8-byte (64-bit) random salt. Neither value can be overridden by the caller.

Both values are far below current guidance (OWASP recommends on the order of 600,000 iterations for PBKDF2-HMAC-SHA256, and NIST recommends salts of at least 128 bits), so the key-stretching work factor is roughly 300 times lower than intended and the short salt reduces the cost of precomputation across keys. The symmetric encryption (AES-256-CBC with a 16-byte random IV) is not affected; the weakness is entirely in the derivation strength. An attacker who obtains one of these exported blobs (for example from a backup, configuration repository, object storage, or logs) can mount a cheap offline dictionary or brute-force attack against the export password, and success yields the full private key.

This issue affects jose: from 1.10.0 before 1.11.13.

Affected

• jose >= 1.10.0 < 1.11.13
• potatosalad/erlang-jose >= 85fddd89ee56b6f9c19eff7d9cfffeef62c330b9 < 461b261902531ca016190e780bb70862d561a7e0

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

Workarounds

When exporting a password-encrypted private key with jose_jwk:to_der/2 (JOSE.JWK.to_der/2), use a long, high-entropy passphrase, since the weak key-derivation work factor only meaningfully lowers the cost of cracking guessable passwords. Restrict access to exported EncryptedPrivateKeyInfo blobs and keep them out of backups, repositories, object storage, and logs that an attacker could read.