I generate the dynamic hash from something that changes its value all the time. microtime() will do the trick here.

Also, you never unhash a password already hashed, what you want to do is hash the input password with the same algorithm and see if the passwords match each other.

Yes, I store the dynamic hash value in a field with in the users table row.

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".
-m

If they got the users table along with the static hash, it would be virtually impossible for them to brute force the passwords anyway.

Since I am using microtime as a dynamic salt, if they wanted to try and brute force the passwords they would have to try each possible value that microtime can produce.

delayedinsanity : It would not matter what the column was named. If they were smart enough to hack into the database I do not think a renamed hash column would confuse them.

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.
-m

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.

unless you get people from ha.ckers.org web application security lab trying to penetrate your web app and tell everyone about it

then i wouldnt worry so much.

__________________
no signature set

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.

__________________

Icon Rush - Create and Animate Icons