Further, the same salt for every password opens the door a class of rainbow type attacks that precompute the rounds of the hash containing the salt, then computing the remaining rounds for each list in the dictionary of passwords. When done well, this can reduce huge piles of computational effort required to scan a dictionary or passwords. This same concept is also why hash(password+salt) is really weak, you can precompute a lot of the rounds of a lot of different paswords and then go from there with the known salt.

There are deeper attacks too, but the above are just what can be derived from a bit of reading up on how the SHA family of hashes works.

For a closely related problem/solution, reading up on HMAC is quite enlightening.

> If you use the same salt for all passwords then I can easily create a rainbow table consisting of "keyword" + salt hashes and doing so I can crack multiple passwords.

That's not a rainbow table, a rainbow table is a list of precomputed hashes (which you'd just do once on a cluster you pay — of buy from a guy who did — and then store/stash)

But you're brute-forcing the whole table (you can look for matches after each computation) instead of having to individually brute-force each password. But you wouldn't keep the forced salted hashes around since there's no need for them once you've tested the leaked hashes.

Yeah I should have stuck that in quotes. I was trying to keep the explanation as simple as possible.

You are right of course there is no need to keep hashes about once they have been compared against the db.