Should a password salt be stored in its own field in the database?

I've been doing a lot of research to determine best practices for storing password开发者_JS百科s for a system I'm currently developing. So far, I've decided that I'm going to be using a SHA512 hash with an RNG to generate a salt for each password (obviously best practice against Rainbow Tables etc).

Would storing the passwords in two separate fields in the table be too simplistic to determine the password representation in the database (there's a PasswordHash field and a PasswordSalt field)? It may seem like security through obscurity, but I was thinking of storing the salt and the password hash together in one field concatenated together.

Would this "help" at all?

---

It doesn't really matter much. The salt doesn't give away any secrets, in fact, it helps keeping secrets. If you want to impress your database designer friends, keep it in a field of its own. If you want to impress your optimizing friends, keep it with the hash. It's a matter of style, really.

Regarding the salt; you might want to make it long enough to prevent against rainbow table attacks: http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables

---

Store it seperately.

Remember what you are protecting against: The scenario is someone gets a copy of your database and therefore can execute a rainbow-table lookup against the fields, if not salted.

It really doesn't matter if the attacker knows the salt; it's just to stop him from using pre-generated rainbow tables.