Jump to content

What is the point of MD5?


rv20

Recommended Posts

I think that what the rv20 is trying to get at is that he doesnt care what the original value is, if he finds a value that creates that hash it is good enough because even if its a collision it will allow him access to what ever that "password" protected are allows access to.... right rv20 ?

 

I call BS. I already said that several posts ago:

However, in terms of checking the hash of an entered password with the stored hash of the real password, it is irrelevant whether or not you can reverse it because one of the colliding inputs will also match and log you in.

 

Yet he kept claiming that MD5 (and thus hashing algorithms) can be cracked. Not just once, but numerous times. Of course he has demonstrated a few times in this post that he doesn't actually read the posts before responding to them. Failing to understand something doesn't mean it doesn't work, it just means you don't understand it. I don't know how cars work either, but that doesn't mean cars don't work.

 

So now i know to do at least an md5(md5($password . $salt))  and you can't really go wrong.

 

Read back a few pages. Running a value through the same hashing algorithm multiple times increases the risk of hash collisions.

Link to comment
Share on other sites

  • Replies 118
  • Created
  • Last Reply

Top Posters In This Topic

So now i know to do at least an md5(md5($password . $salt))  and you can't really go wrong.

 

Im sorry, but please please please learn to bloody read. As has already been stated, applying the md5 algorithm more than once increases the chance of collisions. Hence it is less secure. Why is that so hard to understand?

 

Incidentally it also means that there is a fixed upper limit on the number of checks you have to perform before you will get a match*.

 

No need for the star -- it's trivially true. There has to be a fixed number of inputs that you have to perform in order to generate all the outputs. Whether or not that's equal to the number of different hashes is a different question (which, incidentally i'm guessing is false -- i bet my bottom dollar that there are collisions within the first |sigma|^32 items [where sigma is the alphabet. I would use 16(hex) but i'm not convinced md5 is limited to hex but i cba to check]).

 

$salt = 'jdhje7usGHSjuio!<sghd09(shj)sgh!dgsj67';
$password = sha1($salt.$password.$salt);

 

Wallah. Computationally secure.

 

What on earth do you mean by 'computationally secure'? Sha1 would require more processing power in order to generate a collision than md5, and a salted password even more so. But that doesn't imply that it is totally secure.

Link to comment
Share on other sites

So now i know to do at least an md5(md5($password . $salt))  and you can't really go wrong.

 

Im sorry, but please please please learn to bloody read. As has already been stated, applying the md5 algorithm more than once increases the chance of collisions. Hence it is less secure. Why is that so hard to understand?

 

Incidentally it also means that there is a fixed upper limit on the number of checks you have to perform before you will get a match*.

 

No need for the star -- it's trivially true. There has to be a fixed number of inputs that you have to perform in order to generate all the outputs. Whether or not that's equal to the number of different hashes is a different question (which, incidentally i'm guessing is false -- i bet my bottom dollar that there are collisions within the first |sigma|^32 items [where sigma is the alphabet. I would use 16(hex) but i'm not convinced md5 is limited to hex but i cba to check]).

 

$salt = 'jdhje7usGHSjuio!<sghd09(shj)sgh!dgsj67';
$password = sha1($salt.$password.$salt);

 

Wallah. Computationally secure.

 

What on earth do you mean by 'computationally secure'? Sha1 would require more processing power in order to generate a collision than md5, and a salted password even more so. But that doesn't imply that it is totally secure.

 

Increased chance, what about 1 zillion to one?

Link to comment
Share on other sites

Incidentally it also means that there is a fixed upper limit on the number of checks you have to perform before you will get a match*.

 

No need for the star -- it's trivially true. There has to be a fixed number of inputs that you have to perform in order to generate all the outputs. Whether or not that's equal to the number of different hashes is a different question (which, incidentally i'm guessing is false -- i bet my bottom dollar that there are collisions within the first |sigma|^32 items [where sigma is the alphabet. I would use 16(hex) but i'm not convinced md5 is limited to hex but i cba to check]).

 

Yeah. I for some reason became unsure before I was about to hit the post button, so I included that in case I wasn't true. I had to leave so I didn't have time to check. I'm 100% sure now though. Especially considering simpler hashing algorithms like modulo operations it's pretty obvious that it's true.

 

Anyway, MD5 does output in hex. The PHP function md5() does anyway. You can represent it in any base you want.

Link to comment
Share on other sites

Increased chance, what about 1 zillion to one?

 

Learn math. That's the shortest answer I can give you because to be honest, it doesn't seem like you've understood any word of what we said so far (or you're ignoring it, I can't really tell).

 

Besides, do you need to quote entire long posts to comment on one statement? If I write an essay on something and I want to comment on something written in a book, I don't embed the entire book within my essay either.

Link to comment
Share on other sites

Increased chance, what about 1 zillion to one?

 

Grow up. Seriously.

 

If I write an essay on something and I want to comment on something written in a book, I don't embed the entire book within my essay either.

 

Unless you need to bump the word count :P

Link to comment
Share on other sites

I would like to give a quick simple example of why you can NOT "crack" a hash

Just say my password was "mypassword" and MD5 hash of that is 34819d7beeabb9260a5c854bc85b3e44

 

Now just say i created a hash of the "this is not my password" + 1000 spaces that could create the same hash, Now as both have the SAME hash, which one was my password ?

 

Theirs no way to know, so even if you find a password that will create the same hash it probably isn't the same password, keeping that in mind just say i MD5(MD5('password').$salt) your need to break a 32+salt charactor password

I haven't tried a 7 letter password the time taken usually goes up,  i would guess exponentially.

It always goes up and yes is exponentially

a simple password like this Pass0% may take awhile

but what about this for a password 5eabbae43f756c1368515e1833c31e14salt (note "salt" at the end)

that is the hash of Pass0% with salt appended

the hash for that is 0395421069be29f359091e944a64dba0

 

now the problem to get the original password you MUST resolved the first hash back to the same as the one it was generated from or you won't have a hash to run the second crack on.

if you don't resolve 0395421069be29f359091e944a64dba0 back to 5eabbae43f756c1368515e1833c31e14salt then you can't even attempt to resolve 5eabbae43f756c1368515e1833c31e14 back to Pass0%

 

Thus you could build a endless list of string that create the same hash but that's all! you can NOT get the original password used

Link to comment
Share on other sites

Daniel, I found this for you;

 

http://www.howstuffworks.com/engine.htm

 

Just to clairfy in my mind that I am increasing my chances of collision using the following?

 

<?php
public function preparePassword($password) {
$md5_password = md5($password);
$salt = $this->controller->getConf('salt');
$prepared_password = md5($md5_password . $salt);
return $prepared_password;
}

 

Ignore the methods, going by what I've read today I'd be better off with the following?

 

<?php
public function preparePassword($password) {
$salt = $this->controller->getConf('salt');
$prepared_password = md5($password . $salt);
return $prepared_password;
}

Link to comment
Share on other sites

snip

 

I know all this but this thread has gone a bit off course from my original post but some of the arguments are also a bit weak also like yours with your example or having the same hash for two different passwords(collisions). According to this site,

 

http://unixwiz.net/techtips/iguide-crypto-hashes.html

 

there has never been a collision found yet for an md5 hash. And anyway collisions don't come into it anyway as it it the hash your are replicating from the password so if you manage to generate the right hash from a cracker ok there could be another "string" out there that produces the same hash but it doesn't matter as you have found the hash for your password.

 

 

Im sorry, but please please please learn to bloody read. As has already been stated, applying the md5 algorithm more than once increases the chance of collisions. Hence it is less secure. Why is that so hard to understand?

 

 

I will need to check up on that the wiki entry for rainbow tables uses md5 (md5 ($password . $salt)) with no mention of collisions. I think your collsions problem is a bit far fetched as from what i have looked at you have more chance of building a rainbow table to crack a salted password than you do of having a collision. I think you talk the talk.

Link to comment
Share on other sites

I have to partially agree with rv20 for the isolated incident of it not mattering whether you know which of the two strings is the "right" password if they both share the same hash.  (Most) scripts are written to compare the stored hash with the generated hash from what the user inputs into the login prompt.  So if user's password is "foo" and it generates a hash of 12345 and I figure out that the hash is 12345 and I "reverse engineer" it and come up with "bar" and enter that into the login prompt... well as far as the login script is concerned, 12345 == 12345. 

Link to comment
Share on other sites

While thats kinda true, using MD5 over MD5 stopes that so if a collision is found its useless!

plus theirs a differents between getting into someones account and getting their "password".

 

yeah..there's a difference as far as words your physically using when stating it.  In principle though, its the same thing, as the point of getting someone's password is to get into their account, because the point of passwords is to restrict people from getting into things.  I will preemptively agree that you can potentially do a lot more damage with the real password than a string that shares the same hash.  That would largely depend on how stupid the user is as far as using the same password for lots of different places and the how different systems go about validating passwords (which is, as mentioned, pretty common for sites to just do a string comparison on the hash).

Link to comment
Share on other sites

Last post:

While that's kinda true, using MD5 over MD5 stops that so if a collision is found its useless!

plus theirs a differences between getting into someones account and getting their "password".

 

there has never been a collision found yet for an MD5 hash.

REALLY!

Oh look here!

<?php
echo md5_file(dirname(__FILE__)."/file0.txt");
echo "<br>\n";
echo md5_file(dirname(__FILE__)."/file1.txt");

a4c0d35c95a63a805915367dcfe6b751<br>

a4c0d35c95a63a805915367dcfe6b751

 

@gevans:

You increase the odds in the second one, however i also use MD5 over MD5

the second code has a 1 in 1.4972881278886E-19 chance of a collision (that's if salt isn't used)

to workout the chances of the first or with salt your need to take into account the min to max length of the salt and password.

 

New: post

Reply to CV:

Well this the main part, this whole thread is about "cracking MD5", not about getting into accounts. no matter what you use, if you allow little common passwords and the user uses them, well that's nothing to do with the encryption strength!

 

NB:Also by adding salt that makes the password harder as the reversed hash would be password+salt, so if the salt was 128chars, then thats a long password, but its nothing to do with MD5!

 

[attachment deleted by admin]

Link to comment
Share on other sites

I have to partially agree with rv20 for the isolated incident of it not mattering whether you know which of the two strings is the "right" password if they both share the same hash.  (Most) scripts are written to compare the stored hash with the generated hash from what the user inputs into the login prompt.  So if user's password is "foo" and it generates a hash of 12345 and I figure out that the hash is 12345 and I "reverse engineer" it and come up with "bar" and enter that into the login prompt... well as far as the login script is concerned, 12345 == 12345. 

 

That is true, but never disputed in this topic as far as I'm concerned. We're disputing the fact that he claims that hashing algorithms can be cracked.

 

If he still believes it to be true, here is another challenge. The following is a hashing algorithm:

function hashMod10($n)
{
return $n % 10;
}

If I run my cell phone number through that hashing algorithm I'll get the hash "4". Now send me a text message or give me a call. I'm looking forward to hearing from you.

Link to comment
Share on other sites

@gevans:

You increase the odds in the second one, however i also use MD5 over MD5

the second code has a 1 in 1.4972881278886E-19 chance of a collision (that's if salt isn't used)

to workout the chances of the first or with salt your need to take into account the min to max length of the salt and password.

 

I increase the odds of collision in the second one where md5 is only used once? I thought after reading this thread that it would be the other way around. If that is the case I'll stick with the original option which hashes a password, attaches a salt and hashes the resulting (hash + salt).

Link to comment
Share on other sites

@gevans:

Sorry, i had to write that post about twice, i meant to say the first one, basically where your hashing are 15 charsator set string of 32 charator compared to X length.

 

re-typed:

You increase the odds when you use MD5 over MD5, however i also use MD5 over MD5

this will have a 1 in 1.4972881278886E-19 chance of a collision (that's if salt isn't used)

to workout the chances of the first or with salt your need to take into account the min to max length of the salt and password.

 

I'm locking this thread now.

Forum Rules

14. Users will not act as though they are staff members,

Link to comment
Share on other sites

so would it be advisable to do and md5 of the password phrase, and then maybe store an encrypted version of the password phrase, and when some one tried to login you would compare both the hashed and the encrypted version for a match, not allowing the user to know your making two comparisons?

 

This would protect from they md5 collision problem... or would this be totally pointless?

Link to comment
Share on other sites

Add encryption would help against collisions but would weaken the whole point, its like saying keep the plain text version as well!

Encrypted data can be cracked (reverted back to the original state) One way encrypted data can not be converted back for example if i used DES256 and encrypted a 400 page word document and have you the password you could get that document original contents, but it i used MD5 your have 32 character string.. you could brute force but lets be practical that's going to take years (i'm not even going to take a guess how long), its like trying to clone a human from a fingerprint..

 

However if you want to highly reduce the collision factor theirs a simple route, store 2 hash's each with a different salt,

 

But with that said, i must stress that MD5 is not the only part of a log-in process allowed chartors and password length are also major parts, to breaks someones password is one thing, but to break it from a hash is  another, its more likely they will try to bruteforce from the log-in screen, as they shouldn't be able to get he hash,

The hash only really takes affect once your system is already compromised.

Link to comment
Share on other sites

Add encryption would help against collisions but would weaken the whole point, its like saying keep the plain text version as well!

[...]

The hash only really takes affect once your system is already compromised.

 

Good Points! It was one of those it seemed like a good idea at the moment things...so it really does boil down to making sure your system isnt compromised...eg. ''In winter time, closing the door wont keep the warmth in if the window is open..''... :-)

Link to comment
Share on other sites

  • 2 weeks later...
Guest
This topic is now closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.