No modern hash function, including "salted SHA" and Unix crypt() is vulnerable to "rainbow tables". Rainbow tables work exclusively against the dumbest possible hashing schemes.
Bcrypt isn't a defense against "rainbow tables"; the hash function bcrypt supplanted (PHK's MD5 crypt) was also not "rainbow-table-able".
Correct me if I'm wrong but couldn't you construct rainbow tables for any hash function which takes a single input (including salted SHA, if the salt is the same for all passwords)?
Of course, you'd need a seriously large set of passwords on your hands for it to be worth the effort, but it could be done right?
(Possibly worth mentioning, possibly not, that if your salts are extremely weak then the combined hash might show up in regular rainbow tables, whether your salts are unique or not - it seems unlikely this would ever happen in practice though)
The point of rainbow tables is that you can pre-calculate them. I wrote some myself for fun, and it does take a while to build stuff up.
Even if someone was dumb enough to use the same salt everywhere, once you know that you would just start brute-forcing, not building a rainbow table for the joy of searching it. (Unless you are into that like me.)
It's a fun academic exercise, but Google seems to be a better rainbow table than anyone can construct on their own. Search for hashes. The results are frightening.
If you're using the same salt for everything, you've very nearly defeated the purpose of using a salt.
No salt means that a password hashes to the same thing, everywhere. A site specific salt means that someone can generate rainbow table to efficiently attack all accounts. A user specific salt means that generating rainbow tables is effectively the same (complexity) as brute-forcing.
