Insufficient PBKDF2 computational effort in danielberkompas cloak and cloak_ecto

Use of Password Hash With Insufficient Computational Effort vulnerability in danielberkompas cloak_ecto and danielberkompas cloak allows an attacker who holds the hashed values and the configured secret to brute-force low-entropy plaintexts much faster than configured. The dump/1 callback that Cloak.Ecto.PBKDF2 (Cloak.Fields.PBKDF2 in cloak before the Ecto code moved to cloak_ecto) injects into a field module calls:pbkdf2.pbkdf2/4 with config[:size] in the iteration-count position. The:iterations setting is validated but never used. With the cloak_ecto defaults (iterations: 600_000, size: 32) each hash runs 32 PBKDF2 rounds instead of 600,000, so offline guessing of values such as email addresses costs about 18,750 times less than configured. This issue affects cloak_ecto: from 1.0.0-alpha.0 onward; cloak: from 0.7.0 before 1.0.0-alpha.0.

The CNA records the following affected ranges:

• cloak_ecto on Hex: affected from 1.0.0-alpha.0 onward; other versions are listed as unaffected.
• danielberkompas/cloak_ecto on Git: affected from commit a8fa164 onward; other commits are listed as unaffected.
• cloak on Hex: affected from 0.7.0 before 1.0.0-alpha.0.
• danielberkompas/cloak on Git: affected from commit 8699e64 before 681c970.

These products and branches must be assessed separately. Extracting the Ecto code from cloak does not show that cloak_ecto was corrected, because the separated package has its own recorded affected range.

The affected component is Cloak.Ecto.PBKDF2; in earlier cloak code, the corresponding component is Cloak.Fields.PBKDF2. The injected dump/1 callback calls :pbkdf2.pbkdf2/4 but passes config[:size] in the position intended for the iteration count. The :iterations setting is validated but is not used by this call. With the default configuration of iterations: 600_000 and size: 32, each hash performs 32 PBKDF2 rounds instead of 600,000, substantially reducing the intended work factor. The attacker-controlled material is the guessed plaintext, after the attacker has obtained the stored hashes and the configured secret. The available evidence does not identify a specific network endpoint or an execution path other than this callback.

• Reachability: The guessing phase is offline after the attacker obtains a database dump containing the hashed values and the configured secret. The supplied attack metadata marks network reachability, but the technical description does not identify a specific endpoint.
• Preconditions: The attacker needs both the hashed data and the configured secret; the vulnerability does not itself provide those prerequisites.
• Authentication and interaction: The normalized record describes no privileges and no user interaction as required once the prerequisites are met, with low attack complexity.
• Status: The CNA publishes a proof of concept that validates the actual round count. The available evidence does not identify an active campaign, victim, or ongoing exploitation.

• Confidentiality: An attacker with the database dump and secret can test low-entropy plaintexts at a much lower cost than the configured work factor allows.
• Data scope: Predictable or small search-space values, such as email addresses, face greater exposure. The evidence does not claim that every plaintext can be recovered.
• Privilege and scope: The documented effect is primarily weakened confidentiality for hashed values. No documented path directly changes data or affects availability.
• Operational limits: Fixing the issue requires recomputing stored hashes, which may require coordinated code deployment and data updates.

The flaw can expose the original plaintext for low-entropy values, such as email addresses, from stored hashes. The direct consequence is loss of confidentiality for data protected by the PBKDF2 field; the advisory does not describe a path to modify records or disrupt service through this issue.

Risk depends on whether an attacker can obtain the database dump and secret, as well as how guessable the plaintext is. Correcting the derivation requires recomputing stored hashes because the old values will no longer match the corrected hashing process.

1. For cloak_ecto, the available evidence does not identify a fixed release. Apply the documented workaround by overriding dump/1 in the field module so it calls :pbkdf2.pbkdf2/5 with the configured :iterations and :size.
2. Recompute all stored hashes after correcting the derivation. Existing values will not match the corrected output.
3. For cloak, 1.0.0-alpha.0 is outside the affected semver range because the Ecto components were extracted into another package. Applications using cloak_ecto must still address that package's affected range separately; upgrading only the wrapper package does not show that stored hashes or the PBKDF2 implementation were corrected.
4. Verify with tests that dump/1 uses the configured iteration count, then deploy a coordinated hash recomputation before treating the data as protected again.

• Inventory dependency manifests, lockfiles, and deployment artifacts for cloak and cloak_ecto, then compare the installed version or commit with the affected ranges.
• Identify field modules using Cloak.Fields.PBKDF2 or Cloak.Ecto.PBKDF2; do not rely only on the presence of :iterations in configuration, because the setting can be validated without being used.
• Review each field's :secret, :iterations, and :size configuration, and identify which data is stored as a PBKDF2 hash.
• In a test environment, call dump/1 with a controlled value and verify that the result is derived with the configured :iterations, rather than only with :size.
• Review access to database dumps and secrets as a precaution. The advisory does not define a specific log event or IOC; absence of matching log evidence does not prove that data is safe.