Ah, I did not know that. And I wrote some password hashing with a global salt myself. So I stand by my comment with "one laughing and one crying eye". I thought salts were mostly against precomputed rainbow tables for specific hash functions, but of course if my hashes are valuable enough, a global salt makes cracking them easier than if I used a random/unique one per hash.

This is why programmers should stop trying to write their own password systems.

To be exact, programmers should stop using their own password systems (unless - well, let's not go there :).

Writing them is actually an excellent exercise, and humbling one too. Especially if you show your code to some skilled hacker / security expert.

From what I understand rainbow tables are not really used anymore -- they were useful when it took longer to calculate hashes, but nowadays you just need a decent graphics card to calculate a few billion hashes (MD5 or SHA1) PER SECOND.

Per-hash salts don't really slow that down at all, unfortunately.

Short-version: don't use the hash algorithms that are designed to be fast for protecting sensitive data; use something solid with a work factor instead.

Pepper is the more common term I've seen for a global salt - although I've never seen it implemented independently of a salt.

Isn't there value in having a long global salt to make bruteforcing harder in case the database but not the server code is compromised, though?

Think about it like this: Using a SHA256 + global salt is nothing different from using SHA256 with a different set of constants/initial values.

True, but if the global salt is secret, it'll at least make it slightly harder for the attacker to figure out the password.

For example, if the password is "a" and an unique salt is available in the database, it'll be trivial to brute force. If the password function is something like this, however: sha256("longsalt" + password + salt) the attacker will first have to figure out longsalt which can be slow if it's long.

Or am I completely mistaken?

If you can steal the password hash database, stealing the shared "salt" is usually going to be trivial. Second, lots of hash functions are vulnerable to length extension attacks, so even if extracting the shared secret directly is hard, you can probably exploit the system to see what an empty password hashes to and then use that as a basis for brute-forcing the rest.

In other words: there is a reason why security experts and cryptographers recommend the password storage mechanisms they do.

I see, that makes sense. Thanks for explaining!

But if hackers can break in and steal your database, they'll probably also be able to steal the global salt.

The recent MongoHQ breach is a counter example.