From what I understand, salts are called "salts" rather than "keys" because they are allowed to be public.
That's only part of the story. Keys are used in a reversable encryption operation. A hash is designed to be irreversible. A Salt in a Hash is more like what encryption routines call an Initialization Vector. The intent is to make it unique.
However, isn't going from salted password to hashed password trivial if the salt is public?
The salt is not public. It is stored alongside the hash. A database of stolen hashes is harder to crack if each has a unique salt, even if all the salts are known.
from my other answer to a related question:
You should be using a Slow Password Hash. (i.e. bcrypt) By 'slow' I mean computationally expensive, taking more than 100ms (on your hardware) with DoS protection * to test a single password. This is to increase the processing power needed (on attacker hardware) to find the password by brute force, should the hash be stolen.
Per-user unique salt is highly recommended. (in the case of bcrypt it is automatically generated) Salt should be highly unique (i.e. long & random). Using unique salt means an attacker would have to run a separate brute force Job for each user.
If there were 'no salt', the attacker could instantly use a Rainbow Table and no brute force at all.
If you use a 'shared salt' only, then an attacker could crack passwords for all users with a single brute force Job. (not as quick as a rainbow table but still much easier than a separate brute force Job for each one)
* As @Navin commented, this would be a potential DoS attack vector. One solution is to limit the number of hourly attempts per IP, and per username. It is also possible that you should reduce the 'slowness' of your hash to only take 10ms. This is not nearly as good as 100ms from a 'stolen hash' perspective, but still way better than 'microseconds'.