Using a site-specific constant combined with the user's e-mail as the salt isn't too horrible.
The owasp link you provided explains the two goals of using a salt:
1) Not being able to tell two passwords are identical based on the resulting hash. The e-mail is unique per user, so even if a bunch of users have "password" as their password, the hashes will all be different. Yes, if a user changes their password from "password" to "password" then the hash remains the same, but this is a very minor problem.
2) Prevent rainbow attacks. The constant part of the salt is enough to demand a site-specific rainbow table, and the e-mail takes this even further to a site + e-mail combo. Thus rainbow attacks would only have value in targeted attacks against a known site constant & e-mail combo. Once a good table is complete, it won't matter if the user changes their password.
Using a unique random salt would solve these two issues, however they can also be solved by adding a simple timestamp of the password's initial hashing time to the salt.
A site specific constant is often called a "Pepper" as an aside. Just helps people google it if they want more information.
Several implementations utilise a Salt + Papper (unique per user value and single per site value). A Pepper is particularly useful when it is NOT stored in the database (e.g. stored in an environmental variable or even code). That way if someone steals your database via SQL Injection or a database backup file, they'd have to break the Pepper to recover passwords.
Peppers only make sense when they're almost "free" to implement. A slow hashing scheme is the most important thing, then unique salting, and finally a pepper last (since a pepper adds the least security wise).
site-specific content (or formulaic derivations based on other columns likely to be in the same DB dump) suffer from internal (or former internal) bad actor problems as well. Disgruntled (or just loose-lipped) ex-employees can leak the formula or constant and you have a false sense of security.
(I'm not arguing it's "too horrible", but I am saying that it's worse than other schemes that aren't significantly more burdensome.)
Yes absolutely this - I was just trying to explain how salts should implemented - in the real world always use something like bcrypt or scrypt that does all this for you.
OK, I think I got my terminology wrong. But my thinking was that as well as using bcrypt or whatever on the info in the database you can add some random value stored in code rather than in the database so if your database is compromised it's still a job for them to crack it. Not quite sure what you call that.
Each record should have a unique, random salt. You then store salt:hash(salt+password).
There are numerous guides on how to do this properly, for example https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet