Here's a question - would storing the 2nd salt in separate database (with a different user and password from the user data database) from the user data, and just joining the two in a select statement add yet another level of security here?

That way, even if somehow a "bad man" got access to the user data database, he'd still have to figure out a way to get access to a SECOND database to get the 2nd salt needed to crack the hash? (Crack and hash? Holy crap ... hope the DEA isn't reading this stuff! :P )

Of course, then the question becomes what kind of a hit on the server does it become, and how does it scale?

I think what probably needs to be weighed isn't just how secure it CAN be, but how secure does it NEED to be. If your DB holds confidential/personal/credit card data ... NEED is pretty darn high. If it holds your shopping list for next payday, the world won't end if someone gets in and screws with it.

Great, basic password security post . There's a lot to learn here if you're new to programming. Good job.

Dig - That would add a very small layer of security. But if they can crack it once then they can crack it twice. You're just making the time it takes to get the complete password longer which is a good thing but probably isn't worth the resources/complications. If you want to get any more secure than this you really need to look into server security. It's possible for someone to access your server files and read your source code sending your database info, hash methods, etc. to the hacker. Another good thing to do to get more secure is the use of SSL (Secure Socket Layer). Besides all that you should be as secure as you would ever need to be without being some whitehat hacker security expert for some billion dollar bank.