[RESOLVED] Reverse Md5 Hash

Shawazi

If I convert a password to an md5, is there a function to decrypt it?

tekky

Shawazi wrote:
If I convert a password to an md5, is there a function to decrypt it?

Shawazi

Okay, I thought not becuase that would just create security issues. Why is it then that there are certain security functions in PHP that allow encryption and decryption? Couldn't a user take the encrypted info and plug it into their own scripts to decrypt?

tekky

for some uses, the ability to encrypt and decrypt is required... like secured communications.... clients system encrypts, sends it, serverside decrypts and processes, encrypts reply, and sends to client system....

thats why there are decryptable encryptions 😉

Shawazi

I am currently trying to make secure cookies for a forum I am programming, which is why I ask. But let's say I have this code on a site within a server hosting many sites.


$fusername = "Shawazi";
setcookie("yourlogin", $fusername, time()+60*60*24*365 );
setcookie("yourhash", md5($fusername), time()+60*60*24*365 );

Then, if a user has a cookie with different info, what keeps them from running a script on a different site on the same server like:

echo md5(Shawazi);

Would they then be able to change their cookie info to match mine?

tekky

Shawazi wrote:
I am currently trying to make secure cookies for a forum I am programming, which is why I ask. But let's say I have this code on a site within a server hosting many sites.
$fusername = "Shawazi";
setcookie("yourlogin", $fusername, time()+60*60*24*365 );
setcookie("yourhash", md5($fusername), time()+60*60*24*365 );
Then, if a user has a cookie with different info, what keeps them from running a script on a different site on the same server like:
echo md5(Shawazi);
Would they then be able to change their cookie info to match mine?

before you encrpyt it (if thats what you plan on doing) add a "randomish" in the fact that a user wouldnt know what was added, piece of data to the information to be written to cookies.... OR instead of storing all the data in a cookie, store an ID and reference that ID to an SQL database where you stored the relvent information + a method of verifying its the same person IE. IP or hostname)

Shawazi

Well you did not answer that important question though. If the person knows what is having md5 done to it, can they replicate it on my server and/or their own servers? IPs are no good for dynamic IPs.

Drakla

You can use the cookie path to limit where it's read.

Also don't set the hash with just the md5 of their username, hash it with that and a 'salting' string known only to you $hash = md5($username + 'scrappydappydoo'); and then you check against that when it comes in. I create a hash of the username, a salting string and a unix timestamp and also set a cookie with the timestamp in, which is also a good way of limiting a user's login time.

tekky

Shawazi wrote:
Well you did not answer that important question though. If the person knows what is having md5 done to it, can they replicate it on my server and/or their own servers? IPs are no good for dynamic IPs.

if that is what you are worried about then dont name the cookie names so obviously....

intead of username use chevy or bronco or giraffe, instead of password use oswald, herring, or johnny5.....

and thanks Drak, I couldnt think of the term for it, but salting is what I was trying to get at 😉

laserlight

Why is it then that there are certain security functions in PHP that allow encryption and decryption?

Are you thinking of the mcrypt extension? MD5 is not a cryptosystem, it is a crytographic hash algorithm. Cryptosystems alter messages such that only a designated group of people are able to read them in original form. Cryptographic hash algorithms condense messages such that the resultant hash has certain properties, among them being that it is computationally infeasible to obtain the original message given the hash, or to find two messages that hash to the same hash.

Couldn't a user take the encrypted info and plug it into their own scripts to decrypt?

They could, if they had the secret key, but that is something they should never have unless authorised.

If the person knows what is having md5 done to it, can they replicate it on my server and/or their own servers?

Yes, of course. If you have the original message (a.k.a. the pre-image), you can always calculate the hash.

The question I would ask here is: what do you mean by secure?

Shawazi

I like that solution very much Drakla. I never buy the ambiguous file names becaus a good hacker will just check everywhere anyway and eventually figure it out. However, if I just use a timestamp, no one other than the proper user would know the timestamp they signed up on. The only way a person would be able to replicate the hash is to know the timestamp the other user signed up on which is virtually impossible, correct? So I have just one more question. What is that line needed at the top of each page to avoid xss (xxs?). So if a user sends someone else to a link they cannot gather their cookie information with frame tricks.

laserlight

However, if I just use a timestamp, no one other than the proper user would know the timestamp they signed up on. The only way a person would be able to replicate the hash is to know the timestamp the other user signed up on which is virtually impossible, correct?

That's true, but then Drakla also sets a cookie with the timestamp, i.e. your system must also be able to calculate the hash in order to verify it. The secret part of the pre-image that Drakla uses is the salt, which may be static and unique to a particular implementation of the system.

As such, even with the non-secret portion of the pre-image (the username in this case) and the timestamp, one cannot just change the timestamp (and corresponding cookies) and obtain a new valid hash, since the salt is unknown.

Shawazi

If the code is open source, as I intend it to be for this program, anyone can open it up and view the salt. If I write anything that will not be open source, though, I will most definately add in a static salt.

tekky

and that is where config files and setup scripts come in, let the user configure any settings that need setting and store them in a PHP file as variables so that the file cant be downloaded and reviewed....

Drakla

Tekky's spot on with config files - but you can even make it static and create a hash with something that's not sent to the cookie, but is present on the system relative to that user - e.g. you set cookies of the userid and timestamp and then set a cookie with a hash of something non public, something like the timestamp now + salting string + the timestamp of when they joined, as even if you show their joined date you don't show it to the second. You can even throw their password (may be a hash itself) into the mix as that'll be publically hidden.

toplay

Shawazi, as has been pointed out there isn't any particular MD5 decryption function, however, the MD5 hashes can be broken (not quickly or easily but it can be done). I don't recommend using it for passwords and other important or sensitive information. I would use the libmcrypt extension instead. Use long keys and make sure you store the key off the web or public directory at your site (or recommend that if it's open source). If you can't install the libmcrypt extension (or for open source not everyone will have mcrypt available), then you can use a home grown type of encryption and decryption routines. Here is an example of one:
http://www.phpbuilder.com/snippet/detail.php?type=snippet&id=1290. It may not be the most secure but it's adequate, considering you can change the key and it uses an IV number. Here's some sample output from it:

SAMPLE 1:

Original text: Hello World!

IV number generated: 311

Encoded text: URAyxFbAtJwqe9oq0P

Text after decode: Hello World!


SAMPLE 2:

Original text: Hello World!

IV number generated: 76

Encoded text: UMXyM4bMcJcse6Rqc5

Text after decode: Hello World!

I think it's generally best to use mcrypt whenever possible and pick one of the many ciphers available. I recently became aware of a PEAR script that can do a blowfish cipher without mcrypt. It can be found at: http://pear.php.net/package/Crypt_Blowfish

I downloaded it to give it a quick try. It works and produces the same encrypted value as the one used by mcrypt (important thing to test). The heart of this script is a class inside Blowfish.php.

It actually looks to see if mcrypt is installed, and guess what? Yes, you guessed it! It uses mcrypt if it's installed. It does work without it installed too, but if mcrypt is installed it uses that instead of it's own code.

I decided to quickly try some elementary speed tests on encrypting and decrypting with this new Blowfish.php class. I tested the class with and without mcrypt installed to see the difference in speed if any. I used a simple key: 'A very secret key' and a small amount of text to encrypt: 'This is a test'

I used my Windows XP Pro 3Ghz machine with PHP 5.0.4 under Apache 2, and the results are below.

Average times using Blowfish.php class without mcrypt installed:

Seconds to encrypt: 0.047564029693604

Seconds to decrypt: 0.00019288063049316

Average times using Blowfish.php class with mcrypt installed:

Seconds to encrypt: 0.00062704086303711

Seconds to decrypt: 5.0783157348633E-005

It was interesting to see that with mcrypt installed the decryption time went considerably up (slower) while the encryption time was faster.

So, of course I had to test the mcrypt by itself. Below are the results.

Average times using just mcrypt (not the new Blowfish.php class):

Seconds to encrypt: 0.00064682960510254

Seconds to decrypt: 0.0006110668182373

It is clear to me that using mcrypt has an overall significant speed performance gain than using the Blowfish.php class (with or without mcrypt installed).

If one doesn't have mcrypt installed, then of course this is a pretty good class to use (but still needs the PEAR package to be installed).

I was debating whether to provide the following information/links or not. I decided to present it to educate people about the use of MD5 and since the information are already readily available on the Internet.

You can download a Windows program that cracks MD5 hashes (although I've only seen it crash more than work):
http://members.cox.net/geno023/MD5Cracker.zip

Here's a PHP command prompt script that is supposed to crack MD5 hashes and keys:
http://www.securiteam.com/tools/5XP0X0040G.html

You can even submit an MD5 to be cracked online for free (they've had success with 8 characters and less):
http://www.passcracking.com

Password guessing:
http://packages.debian.org/testing/admin/crack-md5

A 2004 Article on the MD5 (and SH-0, SH-1) vulnerability:
http://www.technewsworld.com/story/35926.html

Cracking MySQL's MD5() function with the rainbow project (see below this):
http://alan.blog-city.com/cracking_mysqls_md5_function__within_seconds.htm

Project RainbowCrack:
http://www.antsight.com/zsl/rainbowcrack/

It doesn't use the brute force method but it can't handle salts either. RainbowCrack creates a table precomputation which is to precompute and store encryptions of a chosen plain text and corresponding keys for all possible keys. This takes a long time to create the tables. But once created some MD5 hashes can be broken in seconds. There's a configuration they have for lowercase alphanumeric values between 1 and 8 characters long that would literally take weeks (or months) for it to compute the tables on my computer. And you would need 36 GB of space. If you did it though, then you could crack at a 99% success rate. But remember, that's only for up to 8 characters (lowercase alphanumeric).

Let's say I wanted to crack all the letters and symbols of the alphabet (including spaces) and the original plain text could be between 1-20 characters long. Well, that would require a lot of disk space and time if I was running it just on my computer. It will take about 587898660426650803072995226 years to compute such a table. LOL, I better get started then!

I hope all this helps.

🙂

laserlight

however, the MD5 hashes can be broken (not quickly or easily but it can be done). I don't recommend using it for passwords and other important or sensitive information.

Assuming you use a strong password, your password is safe. The reason is of course that the pre-image space is large (or should I say infinite?), while there are a fixed number of possible hashes. At some point it may be possible to find a pre-image that hashes to a given MD5 hash, but there is still no guarantee that the pre-image found is the one that matches the original pre-image (in this case your password).

MD5 itself is broken, but the attacks are collision attacks, not pre-image attacks, i.e. it is possible to find 2 pre-images that hash to a given hash. This sort of attack has no bearing on passwords, however, since by definition the original password is not known to the attacker.

That said, until PHP natively implements the SHA-2 subfamily of cryptographic hashes, one should probably use SHA1 instead of MD5 where one needs a cryptographic hash algorithm without relying on mcrypt.

If you can't install the libmcrypt extension (or for open source not everyone will have mcrypt available), then you can use a home grown type of encryption and decryption routines.

That is not a good idea unless you have experience in implementing cryptosystems - it is easy to go wrong. Worse still, if you're not a cryptographer and try to come up with an encryption algorithm yourself, you are likely to screw up and come up with something laughable to the experts.

Anyway, for the most part, mcrypt itself is Free/Open Source Software, so the main problem would not be that mcrypt is unavailable, but that it is not installed - something which can be fixed if the server admin agrees to it.

Weedpacket

Although note that SHA1 has now also fallen to collision attacks; so at present it's no more or less secure than MD5.

laserlight

Weedpacket wrote:
Although note that SHA1 has now also fallen to collision attacks; so at present it's no more or less secure than MD5.

Not really - collision attacks dont apply here, and the collision attacks demonstrated for SHA1 still arent feasible in practice.