Yeah, I wrote that really quick on my way out the door to school. I worded myself wrong regarding "unhashing". So technically if a hacker gets your users table, they have part of the salt too, but chances are they don't even realize it, as I'm willing to bet you don't name it "password_salt".
Well why couldn't it? If you used a regular unix timestamp or even mysql's datetime, which you could then translate into the timestamp, as your dynamic hash and had it stored in a field which was called say, "registered_on", how do they know you're using that as a salt? It just looks like you're recording the timestamp of when they signed up.
Security isn't just locking the door, sometimes it's making the door hard to find.
as for the formula that they use i doupt anyone knows that because its a secret, well unless you work for them.
its probably sha1 or something stronger but i dont think there are people out there trying to crack md5 or sha1 encryptions unless they have a real good reason.
so unless your trying to run something that stores a users account information that has to deal with money or very very personal information like social security etc.. then i wouldnt worry about making your database too security proof.
For my projects I use a combination of 2 salts (1 Static, 1 Dynamic). When a user registers to my website the backend will generate a random salt key for each user. Even if 2 different users register to my website with the same password, the resulting hash will be different.
So if the database was ever hacked or stolen, they would be missing the static salt key, thus it would prove to be impossible for them to bruteforce any of the passwords.
However I'll touch wood, just incase.
they could still brute force it, but they would need the salt in order to get it, they would see $password.$salt they could just start taking things off and see what happens. Even tho im sure nobody is stupid enough to just take the database without looking at the files. There is always something important there.