I have just read many, many articles on SO about hashing passwords with salt but I just cannot find an answer to the particular query/confusion I have.
Let's say I have just done this method for adding a password and salt to the DB:
If this is correct, what happens when an attacker gets access to my DB? Surely if they can read what the salt value is for that hashed password, they can work out what the hashed password is without the salt and then use a rainbow table? Or is it a good idea to encrypt the salt value too with something that is reversible?
If the salt value is stored in plain-text, I just cannot see the point of it. Please enlighten me?
The steps you outline are correct.
If the attacker accesses your database, he has to do a brute force search of the possible passwords plus the random salt. If you use a 64-bit reasonably random salt, then there won't be two entries using the same salt, so any rainbow table attack only works for (at most) one salt value at a time, which makes the rainbow table attack too expensive to be worthwhile. (You can even check to ensure that there is no other password using a given salt when you establish the salt for a user.)
The point of the salted hashed password process is to make it computationally infeasible to precompute possible password hashes, because the random salt screws up the precomputation process.
It also means that if the same password is used at different sites, it won't be obvious by simply looking at the (salted hashed) password values - because the salts will be different at the different sites, so the resulting hash value will be different. (Of course, if the password is discovered for one site, then the attacker will try that password first at the next site; it is still best not to use the same password in multiple locations. But the fact that the same password is in use is hidden.)