>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3590533. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !6 >>> <h3>Problem/Motivation</h3> <p>The 2.x line of <code>FuzzyConfigKeyProvider::encrypt()</code> / <code>decrypt()</code> has three cryptographic issues that together weaken the encryption-at-rest guarantee this provider is meant to give:</p> <ol> <li><strong>Wrong key derivation.</strong> The code does <code>base64_decode(Settings::get('hash_salt'))</code>. <code>hash_salt</code> is not base64-encoded &mdash; Drupal's installer happens to generate a URL-safe-base64-like string, but operators routinely override it with arbitrary content (env var, secrets manager, custom installer). <code>base64_decode()</code> on non-base64 input silently drops invalid characters and returns garbage of unpredictable length. <code>openssl_encrypt()</code> with AES-256-CBC silently accepts any key length, so encryption "succeeds" either way but with much reduced (sometimes negligible) entropy.</li> <li><strong>No authentication.</strong> AES-256-CBC by itself is unauthenticated. An attacker with write access to <code>config</code> storage &mdash; which is exactly the threat model where you would bother with a key provider &mdash; can mutate ciphertext, and <code>openssl_decrypt()</code> will return corrupted plaintext rather than failing. For a provider whose explicit purpose is storing sensitive key material safely, this is the wrong primitive.</li> <li><strong>No format versioning.</strong> Stored values are bare <code>base64(base64(ciphertext) :: raw_iv)</code> with no algorithm or version marker, so once issues (1) and (2) are fixed, existing values become unmigratable: there is no way to tell old format from new at decryption time.</li> </ol> <p>The implementation is a port of a 2014 <code>bhoover.com</code> tutorial (link in the comment block) which assumed a pre-base64'd encryption key; the assumption did not get stripped when the code was adapted.</p> <h3>Steps to reproduce</h3> <ol> <li>Set <code>$settings['hash_salt'] = 'plain-text-secret-not-base64';</code> in <code>settings.php</code>.</li> <li>Create a key using the Fuzzy configuration provider, give it any value.</li> <li>Read the stored <code>configuration.key_value</code> &mdash; encrypted, but with an AES key derived from <code>base64_decode('plain-text-secret-not-base64')</code> which silently drops the non-base64 characters and returns something much shorter than 32 bytes.</li> <li>Tamper with the ciphertext bytes in storage, save the config, read the key value back &mdash; decryption returns garbled plaintext rather than reporting tampering.</li> </ol> <h3>Proposed resolution</h3> <p>Ships as a <strong>2.1.0</strong> minor release. Public API is unchanged and the migration is fully automatic, so a major bump is not warranted under Drupal contrib convention.</p> <p><strong>Switch to AES-256-GCM with proper key derivation.</strong> AES-GCM is authenticated (any tampering causes <code>openssl_decrypt</code> to return FALSE). The encryption key is <code>hash('sha256', hash_salt, true)</code> &mdash; a stable 32-byte key regardless of whether <code>hash_salt</code> is base64-shaped or arbitrary text.</p> <p><strong>Introduce a versioned storage format, starting at v1.</strong> The legacy stored values from 2.0.x have no version marker at all (this is the bug that prevents safe migration in the first place), so the new format is the first explicitly-versioned one &mdash; labelled <strong>v1</strong>:</p> <ul> <li><strong>v1 format</strong> (new writes from 2.1.0 onward) &mdash; literal <code>v1:</code> followed by <code>base64(iv || ciphertext || gcm_tag)</code>. AES-256-GCM, key = SHA-256(hash_salt).</li> <li><strong>Legacy format</strong> (read-only, 2.0.x writes) &mdash; the unversioned CBC blob, recognised by the absence of a <code>v</code><em>N</em><code>:</code> prefix. Decrypted with the old AES-256-CBC + <code>base64_decode</code> key-derivation path, so sites upgrading from 2.0.x keep reading their stored keys until the post-update migration runs. 2.1.x never writes the legacy format. The read path is expected to be removed in a future major.</li> </ul> <p>The prefix is unambiguous: a legacy-format stored value is a pure base64 string (alphabet <code>[A-Za-z0-9+/=]</code>), which cannot contain the <code>:</code> character at any position. So <code>v1:</code> as a prefix cannot collide with legacy data.</p> <h3>Upgrade path for existing sites</h3> <p>Two layers, no operator intervention required for the default flow:</p> <ol> <li><strong>Automatic migration via <code>hook_post_update_NAME()</code>.</strong> On <code>drush updb</code> after upgrading to 2.1.0, a post-update walks every <code>key.key.*</code> config entity whose provider is <code>fuzzy_config</code>, reads the stored value through the legacy fallback decrypt path (still works against the existing <code>base64_decode(hash_salt)</code> key derivation), and re-saves through the v1 encrypt path. Idempotent &mdash; entities already in v1 format are skipped. Per-key failures are logged via <code>Drupal::logger('fuzzy_key_provider')</code> and the post-update continues, so one corrupted entity does not block the entire upgrade.</li> <li><strong>Re-runnable Drush command:</strong> <code>drush fuzzy_key_provider:re-encrypt</code> performs the same walk on demand, for sites that want to verify or re-run after the post-update (and for the follow-up rotation work &mdash; see Related below). Idempotent.</li> </ol> <p>After <code>drush updb</code>, all stored keys end up in v1 format with no further action. The legacy read path remains in 2.1.x for sites that defer <code>updb</code> or roll back.</p> <h3>Remaining tasks</h3> <ul> <li>Replace <code>encrypt()</code> / <code>decrypt()</code> with the v1 implementation, dispatching on the <code>v1:</code> prefix.</li> <li>Keep a private <code>decryptLegacy()</code> path that handles unversioned stored values exactly as today.</li> <li>Add <code>fuzzy_key_provider.post_update.php</code> with a one-shot legacy-to-v1 migration.</li> <li>Add Drush command <code>fuzzy_key_provider:re-encrypt</code> sharing the same walker as the post-update.</li> <li>Add kernel test coverage: v1 round-trip, legacy-fixture read, tampering detection on v1, post-update migration end-to-end.</li> <li>Update the class docblock (the existing one has a stray comma and an odd <code>storage_method =</code> mid-line break &mdash; clean up at the same time).</li> </ul> <h3>Related</h3> <p>A follow-up issue will add a fallback decryption path that tries previous <code>hash_salt</code> values (operator-supplied via <code>settings.php</code>), so that rotating <code>hash_salt</code> on a production site does not silently brick all stored keys. That work depends on this issue's v1 format &mdash; the GCM auth tag is what makes "try previous salts" safe (wrong-salt attempts fail loudly with GCM, silently with CBC). Linking once filed.</p> <h3>API changes</h3> <p>None at the public-method level. New post-update hook and Drush command. Storage shape unchanged on disk (still a single <code>configuration.key_value</code> string).</p> <h3>Data model changes</h3> <p>Stored-value <strong>format</strong> changes for new writes and for the post-update migration; legacy unversioned values continue to be readable in 2.1.x via the fallback path until <code>drush updb</code> migrates them. No config schema changes. No database changes.</p>