Handle Drupal Hash Salt Considerations

[populist]

This is currently a problem:

RuntimeException: Missing $settings['hash_salt'] in settings.php. in drupal_get_hash_salt() (line 1514 of core/includes/bootstrap.inc).

[populist]

This is being worked around in settings.php, but will require a real solution involving writing out to settings.php as part of the installer:

if (isset($_SERVER['PANTHEON_ENVIRONMENT'])) {
$settings['hash_salt'] = 'PANTHEON-LOLWAT';
}

[populist]

The $settings['hash_salt'] is now handled with this logic in settings.php:

if (isset($_SERVER['PRESSFLOW_SETTINGS'])) {
$settings['hash_salt'] = hash('sha256', serialize($databases));
}

Ideally this can be a value that we inject directly into the environment, but for now this is functional and uses the same methodology as the fallback in drupal_get_hash_salt() https://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/drupal_get_hash_salt/7.

[nstielau]

This means that the salt will be changed anytime a database is migrated.
Does that mean that forms loaded in a browser before the DB migration and
submitted afterwards won’t work? If so, that isn’t ideal, but probably OK.

On Wed, Oct 22, 2014 at 2:30 PM, Matt Cheney [email protected]
wrote:

The $settings['hash_salt'] is now handled with this logic in settings.php:

if (isset($_SERVER['PRESSFLOW_SETTINGS'])) {
$settings['hash_salt'] = hash('sha256', serialize($databases));
}

Ideally this can be a value that we inject directly into the environment,
but for now this is functional and uses the same methodology as the
fallback in drupal_get_hash_salt()
https://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/drupal_get_hash_salt/7.

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

Nick Stielau
Director of Engineering
Pantheon Systems

[populist]

In cases where forms are loaded and the database connection information changes before they are submitted, those forms wouldn't work. AFAIK this is how we are handling the hash salt for Drupal 7 via the fallback in https://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/drupal_get_hash_salt/7.

Ideally we can set a hash salt for the site in the site environment that wouldn't change when the database information does.

[joshkoenig]

We have an established mechanism to deploy unique hashes for config values. Look at the internal chef code for dropping PHP config for WordPress. This will make it random for sites, but consistent across envs, but can be reset in the event of a security scare. It's better than what we are doing for D7.

[populist]

We are now rolling with a Pantheon generated hash salt value being used for all Drupal 8 sites. This should maintain consistency across database migrations and site environments.

[ultimike]

I just ran into a related issue with this. I created a new D8 (8.0.1) site on Pantheon, then cloned it down to my local, then tried to import it into Acquia Dev Desktop. When I did, I got an error during site installation that said that the settings['hash_salt'] wasn't set.

I added $settings['hash_salt'] = ''; to the top of my local settings.php (above the settings.pantheon.php include) and this did the trick. Not sure if it is the best way to do it, but since $settings['hash_salt'] is required, then I'd think that anyone bringing a D8 site down from Pantheon will run into this issue.

-mike

[greg-1-anderson]

It is true that the hash salt is required to run Drupal; however, on Pantheon, we inject the hash salt setting rather than write it into a settings file. This keeps sensitive information out of the repository / database, which is better for security.

So, you are correct that it is necessary to add a hash salt value when migrating a Drupal site from Pantheon to another location (different host, local development, etc.). See the discussion on this in #103.

[greg-1-anderson]

Documentation update for this: pantheon-systems/documentation#1121

[joshkoenig]

Re-opening this. It looks like we implemented this in a way that has different salts in different environments, which makes development painful when doing DB clone operations.

[greg-1-anderson]

If I am not mistaken, the hash salt is only used to protect your login session data / prevent CSRF. This means that you cannot be simultaneously logged in to two sessions in two environments in the same browser; is that the development pain you are referring to?

If users do not like Pantheon's handling of the hash salt could always set $settings['hash_salt'] in their settings.php file. To do this without interfering with your live site sessions, you can fetch your current live site hash salt value with Drush:

$ drush @pantheon.mysite.live ev 'return getenv("DRUPAL_HASH_SALT")'

Then, put the result from that command into your settings.php, after settings.pantheon.php is included.

I haven't tried to see if I could have simultaneous logins with this configuration, but it should work. Maybe this workaround would be a better strategy than unifying the hash salt across environments -- which I sort of think is a good feature, as it prevents people from accidentally sharing sessions between dev and live.