A person with the stolen database tables has only 2 fields per user.

    password hash                                  salt
    c32528b3e9191a8c7471252c6de289939a1e6f01       cGFzc3dvcmQ

In the most basic terms, the way I understand it, __all what salting does is make the password more longer__.

The original password was 'password'.  But I appended to the password before computing the hash the salt `cGFzc3dvcmQ` to make `passwordcGFzc3dvcmQ`.  What does that do?  Well, it just makes it so if you happen to have a rainbow table of common passwords and their hashes,

    password                        hash
    password                        5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8

 where you can see at a glance that `SHA('password')=5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8`, looking up the original password from the hash is all too simple.  We want the cracker to have to do some work for it.

So we go "Dyoh! We either prepended or appended THIS RANDOM STRING RIGHT HERE to the original password!  Now your hash tables of __common passwords and their hashes__ are useless"

Which they are.  Because we complexified each password by the random string, basically "making the user's passwords better", and completely screwing up the hashes so they are completely uncommon now.

So salting makes it so __each hash has to be cracked individually__, because to do it, if the cracker has the salts, the cracker has to append/prepend the salt to _each common password_ he tries.  2 different users could use the simple password `password`, but cracking that will be 2 entirely separate jobs for the cracker, because of the salt.  So cracking all the passwords will take longer.

The [article here](http://codahale.com/how-to-safely-store-a-password/) says that because of the compute power available today, however, using salts is trivial to crack.