Hello,

I am writing an app that uses MD5 verification. I have a string that I convert with MD5, and then use an if statement to verify. Like this:

And then I send the information via POST to the next page like:
http://www.domain.com/nextpage.php?member_...7e2237516804824
And on that page I verify that the hash is correct by using the same code:


I am wondering, is there a way to DECRYPT the MD5 hash? Using the code method or something? Without having to send two variables over POST.

The answer is no. MD5 is not an encryption it is a hash. As such the is no "decryption". The only way to find out what the MD5 hash results to (which can be more than one thing) is to brute force it forever....again, brute force is simply trying to create an MD5 that matches the current one. It's not going to decrypt anything.

For your script, if using the member id is needed and you actually need to send it across on POST (not calling it in your "recieving file) then that is the only method you can use to compare the 2 md5s.

Although it's true wath DNW says, md5 is a hash function, md5 isn't very secure though...
I even believe there was a way to come up with the un-md5-ed string (or at least a series of possible matches) back in ipb 1.3 days, in fact I thought it was one of the reasons that in ipb 2.x they now salt the password with an additional md5ed passsalt to avoid reversal of the pass, ...

There is no "reversal" however it is possible for one hash to = more than one bit of text. What you were able to do with pre-salted hashes was just what I said, brute force the hash to find what the hash was equal to. Just with any encryption function, I am sure that md5 could be statistically calculated to atleast approximately correct with some sort of experiment. A very simple brute force could work similar to this:



Obviously the above will not work as it does not load dynamically. I just wanted to give some sort of visual reference to what I mean. Expanding further, as long as the hacked password does not equal the stolen md5 hash we keep trying. On each loop we increment the ascii values based on current length, last used value, etc. Eventually (in the year 5050) we find a hash that does match, but isn't necessarily the original password. Even if it isn't the original it will work in the password field as the created value gets turned into the same md5 value.

Salting basically kills this off. This is because the original password is turned into an md5 hash and the both a random salt and the resulting hash are then hased again. So first a hacker would have to figure out what is and isn't the salt, apply the extracted md5 into the the cracker again and hope they chose right. However, since the salt values are exactly the same characters used to create the md5 hash there is no way to diferenciate between the salt and the original md5. Furthermore, as I said above, since there is no way to know if the "matching" hash is exactly the original value it's near infinatly impossible to actually figure out the values within both md5 hashes.

Hope that made long-winded sense In short, md5's only weakness is that it isn't infinately random and that every hash could never be perfectly unique. However, I think that flaw was fixed I do believe that it would show even more statistical comparabilities than it does now. I think this is heavily outweight by the fact that it is indeed not an encryption, and as such cannot be perfectly "unencrypted". Nothing is perfect, but I think md5 can rival (atleast) a binary compiled ascii script (which is virtually impossible to reverse as well) if not perform even better.

fYI, there are sites (cough*Rainbow Tables*cough) that basically record md5 hashes. They have computers just md5'ing everything under the sun, storing it in a database, and people submit hashes, stored in the database.

Then, what you do is submit a hash, they do a db lookup for a matching string of text. It's the same concept as brute force - but much quicker adn simpler.

And yes, that is why IPB passwords are salted.

What do you mean by salted?

i.e., a single character change causes a completely different md5 hash.

So, say your password is "password" (yes, I know, unique huh).

md5("password") results in a has (we'll just call it abc for now).

You can take that hash, and do a lookup on it, to get the original text that produces that hash - password. There may be other strings of characters that result in the same hash, but it wouldn't really matter anyways.

What IPB does is generates some special characters to append to it.

i.e. "#4/@u"

md("password") may result in abc

but what IPB does is

md5( md5("password").md5("#4/@u") )

The result may be xyz

So, if you got ahold of the hash, you'd have xyz, and you would try to decrypt that. Say if you did, the original text is "monkey" - trying to login to IPB with "monkey" will fail. Basically, IPB adds some random characters (which it records so that it can check the md5 later on) to your password hash so that it cannot be bruteforced through a table lookup.

That's not to say a script couldn't brute force your login page - submit a piece of text, wait for response, failed, try again, etc. But you can't just lookup the hash to get the original text.