[jasey]

Because part of the puzzle is in the source code, and if the attacker got the encrypted user table from the common method of SQL injection they don't know the rule which is defined only in the function which checks validation of the pw and generates the pw hash.

What I do similar is,

Pw_hash = hash('f4/$$er3@' + salt + plain_text_pw);

If the attacker only gets the database (which has the hash and the salt) and not the source code they don't have the 'f4/$$er3@' value needed to perform any attacks

[stouset]

There is zero requirement that salts be kept secret in the event of a password database breach. Salts are to prevent users with identical passwords from having identical password hashes, thereby defeating rainbow table attacks (and other attacks involving attackers being able to reuse work from other accounts).

Your approach offers effectively zero additional security; it is trying to add "features" to salting that don't work towards their actual purpose.

Edit: If you want to have something site-wide that an attacker wouldn't have while decrypting an offline password database, the thing you're looking for is an encryption key.