Maybe I'm missing something obvious...
Are all passwords stored in common, unsalted hash algorithms able to be attacked via rainbow tables?
Not all passwords. When the password is sufficiently long and random to not appear in a reasonably-sized rainbow table, salting is indeed unnecessary.
The purpose of a salt is to increase the length of the password to a level where rainbow tables are unfeasible. When the password already has enough entropy, the salt becomes redundant.
When your salts are 32bit, demanding about 5 more characters of mixed case, letters and special characters without a relation to a dictionary word would be equivalent.
However, passwords used by the average user do not have enough entropy to be rainbow-table-proof. So unless you have the ability and authority to enforce a strict password policy and users who understand that they must not try to find loopholes (hey,
Password123! is 12 characters mixed case with letters and special chars!), you should still use salting.
Yes, though some unsalted hashes, like the outdated Windows LM hash, are even worse due to cryptographic deficiencies.
Asking about salting or not means the asker is interested in storing and securing passwords, not in securing their own account. Even with 128 character fully random passwords, an administrator with access to two sites will be able to see if that 128 character password was reused, unless there is a salt. So yes, all unsalted hashes have an inherent insecurity, even if a given password is safe from a rainbow table attack.
Another problem with unsalted hashes is that two users with the same password will have the same hashed password. This means that if the password hashes are accessible, whether by compromise or malicious insider, then duplicated passwords are obvious. Even if they cannot crack the hash, a social engineering attack on one grants access to all. (Or one of the users sees that they can access the others)
Salting is extremely cheap and there is no reason to be implementing a password storage system without it.
Better yet, ask yourself if you really need to be storing passwords
If you are referring to "common" password hashing algorithms like SHA1 and MD5 that are used without salt you do not even need a rainbow table, a reverse hash lookup database is sufficient for the majority of poorly chosen end user passwords.
md5("password") will always result in
5f4dcc3b5aa765d61d8327deb882cf99 so when you find the hash
5f4dcc3b5aa765d61d8327deb882cf99 you know it's going to be password. Try searching google for
5f4dcc3b5aa765d61d8327deb882cf99 or any other hash you happen to have.
As always, please first read Thomas Pornin's answer to How to securely hash passwords?
The summary for salting, assuming you have more than one password in your database, and that database is leaked (see Sony, Adobe, Forbes, et al.) so an attacker (cracker, criminal, security researcher, bored high school student, competition cracking team, etc.)
With a single salt for all users, usually called an "epic fail"
With no salt at all, or a single salt that's been used before by that attacker (such as "salt")
A salt is basically random values that are appended to a password before they are hashed and stored. The result is that one persons password of "potato" will look different to another persons password of "potato".
Ranbow tables are a massive list of hashes for a long list of different terms and phrases, most commonly for the use of passwords. If your password potato is in a rainbow table a salt will prevent it being broken. If your potato password isn't salted AND it exists in the rainbow table then you are probably out of luck.
The main saving grade you have against an unsalted password is the hope that it is not contained in the rainbow table attacking you. For example, people may create rainbow tables for all the words in the dictionary, but if your password is not in the dictionary and not salted, that rainbow table wont get you.