Drupal reuses its hash salt

Question

The instructions in default.settings.php say

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. If this variable is empty, a hash of the serialized database credentials will be used as a fallback salt.

but this explanation of salting says

A new random salt must be generated each time a user creates an account or changes their password.

and goes on to clarify that each salted hash (eg password) should have its unique salt stored along with the hashed+salted password in the database.

Am I misunderstanding the article I read on salting, or is Drupal using a faulty practice for the sake of convenience, or is the article wrong, or is there something else going on?

Answer 1

I have migrated other CMS's to Drupal and had experience moving user accounts. Drupal's password algorithm is extremely good.

The salt you are referring to in the settings.php is not used for passwords. The drupal_hash_salt salt is used for generation of things like cookies. Hence why it says you must keep it the same across all web servers if you are in a load balanced setup.

Generation of passwords uses the SHA512 algorithm with randomly generated salts using openssl php libraries (not mt_rand or other weak random number generators).

If you want to learn more about password generation you can start here reading the API documentation for Drupal

You see that in the function to generate it calls a "private" function to generate a new password salt (_password_generate_salt()). Which in turn calls a lot of other private, custom Drupal functions (it is a long rabit hole).

So in general the password scheme used for Drupal is extremely deep and nested, it does not use PHP functions considered to be "weak".