How long should my password salt be, and is SHA-256 good enough?

Question

I'm in the process of creating a gaming community site that I'm aiming to release to the public soon. Currently, I'm working on passwords and logins. I've only used MD5 before, but I've read about password safety and heard that salting is currently the way to go.

Here's my plan: Every user has their own unique salt of 12 random characters (#/¤& etc), stored in the users table. The salt is hashed (using SHA-256) along with the password on registration, and re-hashed on login.

How does this sound to you? Anything I can improve? Should I go for SHA-512 and a longer salt, or is this enough?

Answer 1

Your suggestion of 12 bytes should be an adequate length for a salt. That would require a dictionary attack to prepare 2⁹⁶ databases of hashed passwords. Someday this might be a trivial operation for a cracker, but we're still a ways off from that.

SHA256 is recommended by NIST as having adequate hashing strength for passwords, at least for now.

If you want to explore even stronger methods of password security, look into key-strengthening techniques like PBKDF2, or adaptive hashing with Bcrypt. But these have no direct support in SQL. You'd have to do the hashing in application code and then post the hash digest to your database.

It may seem like security overkill for a gaming site, but it's a good practice to do it. Because many users (inadvisably) use the same password for their gaming login as they do for their banking login! You don't want to be responsible for an authentication breach that leads indirectly to major losses.