When you add a pepper you're no longer salting, you're rolling your own MAC, which isn't necessarily a great idea. This is outside the threat model salts are designed to solve, which is to avoid pre-image attacks, so your claim that salting alone is "pointless" is factually incorrect. For a more in-depth look at MACs and why you shouldn't just tack a pepper onto a hash, see this existing answer.

@Xander, I now regret editing my post to take out what I considered to be a nongermane sentance. I would suggest not using a pepper (global salt) in combination with the per-user salts. Instead, encrypt your per-user salts with an symmetric key only known by the web application. That way, the salts remain intact, but if the database is leaked, they are still unknown (at least for a time).

That said, I don't feel that the addition of a constant pepper prefix/suffix to the salt will harm the resulting hash digest in any way due to the Avalanche Effect of modern cryptographic hash functions. The answer you linked to makes some assumptions.

It is fortunate that cryptography is just a matter of feeling well about it, then !

@Lakey So, no. A MAC is an entirely different cryptographic primitive. The properties of a hash function have very little to no bearing on whether or not it will make a strong construction when used as a building block for an entirely different primitive. This is not a sound practice. If you want a MAC, use a proper MAC construction, not a hash with a pepper tacked onto it.

@Lakey As an aside, the author of that answer is a widely known and well respected cryptographer. Just so you know.

Thomas, your answer makes the assumption that a hacker will have access to the entire harddrive, which could happen, but it's much more likely that the hacker will only have access to either the SQL server or the web server, which is why I specifically mentioned that best practice is to host them separately. Statistically, the most likely attack vector is the SQL database, so let's start there: Assume the hacker has downloaded all your hashed passwords and their associated salts. Those salts are meaningless at that point. That is why you need a 2nd salt known only by the web app.

@Xander, I did not suggest to tack a pepper to the hash. I suggested to use a 2nd salt (a global one) before hashing.

@Lakey Yes. This is called a pepper, or in MAC parlance a key. There is no such thing as a "global salt."

And it's not "tacked to the hash". It's added to the first salt before the hash.

"If you use only per-user salts (which are stored in the database), then if your database is hacked & downloaded, the hacker will have both the digests and the salts, which literally make the use of salts pointless." <-- this is wrong. Hashes don't make passwords any more secure, but they aren't pointless. The point of salts is only to require an individualized attack against each user's password.

@AJHenderson, well that's certainly true. I did overstate that point, because they aren't literally pointless, since they still have the effect of slowing down the brute-force process a great deal. With per-user salts (even if they are known), they will still prevent a single computed hash from being tested against a list of all the digests from the database. Apologies for that overstatement.

Additionally, the use of a secret known only to the web server doesn't provide meaningful additional security as it only amounts to security though obscurity. That isn't functional security.

@AJHenderson, that's like saying the username and password to your bank account don't provide meaningful additional security, since they only amount to security through obscurity. The only usefulness of any private credentials is that they stay private. By your logic, you should say the PKI infrastructure is poorly designed because the private key could be stolen.

@Lakey You're missing the point because I wasn't very clear on my first comment. I didn't mean that you literally "tack" a pepper onto a hash after you've computed it. I meant to stuff the concept of a pepper (or key) into a standard hash construction and expect the result to be optimally resistant to attack. If you want to argue that it provides extra security, fine. But in that case, you should be recommending a tested MAC construction like HMAC, and not suggesting that a peppered hash is sufficient.

@Xander, I didn't do anything of the sort. I just stated that you should have both a salt and a pepper. The construction I recommended can be found in the following section which I titled "Implementing the salt", where I specifically state not to roll your own construction, but I linked to a separate answer which does discuss HMAC. What is your issue??

@Lakey - I think the confusion comes from the value you are attributing to having the salt remain hidden. It isn't a bad idea to separate out data across both your web server and the SQL server to make it harder for an attack, but since you don't know what an attacker may have compromised, it doesn't provide meaningful security. In other words, it still doesn't help protect against a bad password since it could be discovered and then would leave the account exposed to simple brute force. A user's password is security because it only compromises their account and isn't stored.

@Lakey This has gone on too long, so I'm going to bow out, but you said in the comments "I don't feel that the addition of a constant pepper prefix/suffix to the salt will harm the resulting hash digest in any way due to the Avalanche Effect of modern cryptographic hash functions" and the answer you link to in the "implementation section" while it does describes peppering and HMAC, doesn't recommend it, while you specifically do. My issue is that you answer seems to show a general lack of understanding of the concepts and applications at hand. Feel free to disagree, and have a good night.

@Xander, ignore my feelings if you wish. That’s just an expression. The fact is, a constant prefix or suffix will not weaken the digest of a modern cryptographic hash function (i.e. SHA256, etc). Nor will knowing the constant prefix/suffix provide an attacker any additional assistance in performing an offline attack. In addition: "There is no such thing as a 'global salt'." I guess not in MAC parlance, but I'm not discussing MAC parlance, am I? I'm describing a salt that is applied globally (e.g. a prefix), thus a global salt. It's not a term; it's a adjective and a noun.

@Xander & AJHenderson, I did make an edit to my answer stating that I was wrong when I said that per-user salts are pointless if known. Thanks for pointing that out.