Enhance hash_salt documentation in default.settings.php

Created on 20 January 2020, over 4 years ago
Updated 12 March 2023, over 1 year ago

The hash_salt setting in default.settings.php has the following documentation supporting it within the file:

/**
* Salt for one-time login links, cancel links, form tokens, etc.
*
* This variable will be set to a random value by the installer. All one-time
* login links will be invalidated if the value is changed. Note that if your
* site is deployed on a cluster of web servers, you must ensure that this
* variable has the same value on each server.
*
* For enhanced security, you may set this variable to the contents of a file
* outside your document root; you should also ensure that this file is not
* stored with backups of your database.
*
* Example:
* @code
* $settings['hash_salt'] = file_get_contents('/home/example/salt.txt');
* @endcode
*/
$settings['hash_salt'] = '';

It's clear from this that the hash_salt should be unique per website, and that the hash_salt should be the same amongst web servers in the same cluster of the same website. However there is no recommendation on whether the hash_salt should be the same amongst different environments (eg, dev/stage/production) of the same website, or whether each environment of the same website should have a different hash_salt.

I asked over in #security-questions if it was a bad idea to use the same hash across dev/stage/prod on the same website. There were a range of answers:

gapple:

Having different hash_salt values prevents tokens (like password reset) from being usable across environments

cashwilliams:

yes [it's a bad idea to use the same hash across dev/stage/prod]

freelock:

Huh, interesting questions, but not sure I agree with the response -- I don't see how getting the hash salt from a dev server can be used to get a valid login link on production -- when you get a password reset link, the code updates a timestamp in the user's row in the database that is part of the hash, so I don't see how that can be exploited without actually requesting a link from the production site.
That said, as I understand it, having the hash salt could make a brute force attack on the passwords database a bit easier (but still really difficult).

Over in #support, I asked the same question:

siliconmeadow:

Good question! I'm not sure, and have often wondered the same.

snufft:

Wouldn't you want the same hash salt across all environments for consistency?

So it seems that there isn't an agreed/documented consensus on what the 'best practice' way is. Can we use this issue to confirm what the agreed best practice method is, and then document it, by adding a comment to default.settings.php?

πŸ“Œ Task
Status

Fixed

Version

10.1 ✨

Component
DocumentationΒ  β†’

Last updated 1 minute ago

No maintainer
Created by

πŸ‡¬πŸ‡§United Kingdom nicrodgers Monmouthshire, UK

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ͺπŸ‡ΈSpain tunic Madrid

    Patch from #13 is the same as #7 but with the wrong extension. I'm hiding it and adding this example to #3339883: Employees of Dotsquares are posting mass re-roll patches which are invalid and/or incomplete β†’ . I would recommend deleting this file.

  • πŸ‡ͺπŸ‡ΈSpain tunic Madrid

    I would move this to RTBC. Patch applies cleanly on 10.1.x, nobody said anything against the change.

    The situation mstrelan describes is real, but it comes from a bar practice and I others issues arise when you use itok on the body. I don't think it is enough to block this change. Also, I don't think sysadmins are going to change their current setup of a running site because this little comment change,

  • Please ignore patch #13 and @tunic thanks for informing me. I will take care of it & never repeat it again

  • Status changed to RTBC over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Change in #7 seems small and easy enough. Lets see what the committers say.

  • Status changed to Needs work over 1 year ago
  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    Fail is genuine, need to update the scaffold file too

  • Status changed to Needs review over 1 year ago
  • πŸ‡ͺπŸ‡ΈSpain tunic Madrid

    #19 is right, we need to patch "/core/assets/scaffold/files/default.settings.php" file, I totally forgot about scaffolding in #16, sorry.

    Since original patch author (roderik) seems inactive I'm adding a patch with that change.

  • πŸ‡ͺπŸ‡ΈSpain tunic Madrid

    Ok, I added a trailing space :(

    One error is from that space char, but the other seems unrelated to this patch:

    1) Drupal\Tests\ckeditor5\FunctionalJavascript\CKEditor5AllowedTagsTest::testMediaElementAllowedTags
    Behat\Mink\Exception\ElementNotFoundException: Form field with id|name|label|value "filters[media_embed][settings][allowed_view_modes][view_mode_2]" not found.
    
    /var/www/html/vendor/behat/mink/src/Element/TraversableElement.php:207
    /var/www/html/core/modules/ckeditor5/tests/src/FunctionalJavascript/CKEditor5AllowedTagsTest.php:386
    /var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
    

    Let's try again, without that trailing space.

  • πŸ‡ͺπŸ‡ΈSpain tunic Madrid

    Forgot patch!

  • Status changed to RTBC over 1 year ago
  • πŸ‡¬πŸ‡§United Kingdom nicrodgers Monmouthshire, UK

    Looks good, thanks for addressing #19, @tunic

  • Status changed to Needs work over 1 year ago
  • πŸ‡ͺπŸ‡ΈSpain tunic Madrid

    Again, strange failures related to CKEditor tests:

    
    Testing Drupal\Tests\ckeditor5\FunctionalJavascript\CKEditor5AllowedTagsTest
    .....E.                                                             7 / 7 (100%)
    
    Time: 02:11.514, Memory: 4.00 MB
    
    There was 1 error:
    
    1) Drupal\Tests\ckeditor5\FunctionalJavascript\CKEditor5AllowedTagsTest::testMediaElementAllowedTags
    Behat\Mink\Exception\ElementNotFoundException: Form field with id|name|label|value "filters[media_embed][settings][allowed_view_modes][view_mode_2]" not found.
    
    /var/www/html/vendor/behat/mink/src/Element/TraversableElement.php:207
    /var/www/html/core/modules/ckeditor5/tests/src/FunctionalJavascript/CKEditor5AllowedTagsTest.php:386
    /var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
    
    

    I've triggered a retest but I don't have faith, it will probably fail again.

  • Status changed to Needs review over 1 year ago
  • πŸ‡ͺπŸ‡ΈSpain tunic Madrid

    Retesting worked!
    Moving to Needs Review.

  • Status changed to RTBC over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Putting back to RTBC since it was random failure

    • longwave β†’ committed beab28f2 on 10.1.x
      Issue #3107548 by tunic, roderik, nicrodgers, greggles, anita_novicell,...
  • Status changed to Fixed over 1 year ago
  • πŸ‡¬πŸ‡§United Kingdom longwave UK

    Committed and pushed to 10.1.x, thanks! I tried to credit everyone who added something to the discussion here.

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.69.0 2024