Topic: What is the point of MD5?

[MadTechie]

editr

[.josh]

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

[MadTechie]

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!

Code: [Select]

<?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]

[Daniel0]

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.

[waynewex]

I'm locking this thread now.

[gevans]

@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).

[MadTechie]

@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,

[DarkSuperHero]

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?

[MadTechie]

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.

[DarkSuperHero]

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..''... :-)

[Daniel0]

Still though, hope for the best, plan for the worst. This is true in particular with programming.

[keenyounglearner]

Could someone explain what the point of a one-way hash function like this is? Why would I hash a password if I can never get the original value back?

[Daniel0]

Let me turn the question around: Why would you want the value back?

[keenyounglearner]

Well I store the users password in my DB on registration then I want to match it again his enterred password upon login. Or is the point to just go if(md5(enterredPassword) == $storedDBHas) { login=true; }

[Daniel0]

Or is the point to just go if(md5(enterredPassword) == $storedDBHas) { login=true; }

Yes.