Hiding a salt is unnecessary.
A different salt should be used for every hash. In practice, this is easy to achieve by getting 8 or more bytes from cryptographic quality random number generator.
From a previous answer of mine:
Salt helps to thwart pre-computed dictionary attacks.
Suppose an attacker has a list of likely passwords. He can hash each
and compare it to the hash of his victim’s password, and see if it
matches. If the list is large, this could take a long time. He doesn’t
want spend that much time on his next target, so he records the result
in a “dictionary” where a hash points to its corresponding input. If
the list of passwords is very, very long, he can use techniques like a
Rainbow Table to save some space.However, suppose his next target salted their password. Even if the
attacker knows what the salt is, his precomputed table is
worthless—the salt changes the hash resulting from each password. He
has to re-hash all of the passwords in his list, affixing the target’s
salt to the input. Every different salt requires a different
dictionary, and if enough salts are used, the attacker won’t have room
to store dictionaries for them all. Trading space to save time is no
longer an option; the attacker must fall back to hashing each password
in his list for each target he wants to attack.So, it’s not necessary to keep the salt secret. Ensuring that the
attacker doesn’t have a pre-computed dictionary corresponding to that
particular salt is sufficient.
After thinking about this a bit more, I’ve realized that fooling yourself into thinking the salt can be hidden is dangerous. It’s much better to assume the salt cannot be hidden, and design the system to be safe in spite of that. I provide a more detailed explanation in another answer.
However, recent recommendations from NIST encourage the use of an additional, secret “salt” (I’ve seen others call this additional secret “pepper”). One additional iteration of the key derivation can be performed using this secret as a salt. Rather than increasing strength against a pre-computed lookup attack, this round protects against password guessing, much like the large number of iterations in a good key derivation function. This secret serves no purpose if stored with the hashed password; it must be managed as a secret, and that could be difficult in a large user database.