Your source code (or a running image of your program, that has the extra salt in memory) is rarely harder to get access to than your password database. Remember

Your source code (or a running image of your program, that has the extra salt in memory) is rarely harder to get access to than your password database. Remember, all of your developers have access to it, and likely have it unencrypted on their machines, which may not be terribly secure. It would be a small enough extra value, and a large enough extra hassle (making it difficult to re-use the same encrypted password in other code, for instance use the same encrypted password for basic auth over HTTPS as you use for your webapp in a different area) that I don't think it's worth it. I also worry that promoting this practice would make some developers think that they didn't need a random, per-password salt as well. It's hard enough to convince developers about the value of using strong key derivation functions and a per-password salt, and if you added a global salt I'd worry that some would think that the per-password salt is not necessary. Then once the fixed salt were compromised, brute forcing individual passwords would become trivial. Also remember, the attacker could easily create an account with a known password, and they can get the normal salt from the password database. Now they just need to brute force the single "fixed salt", and you're back to where you started. No, it's much better to encourage people to just use strong password hash functions, like bcrypt or scrypt, with good, random, per password salts, than to try to apply a little security through obscurity by adding yet another salt that is likely easy to find.