Can Different Inputs Produce Two Exact Same md5()'s Outputs?

Volitics

I'm wanting to process each user's username through the md5() function in order to get a unique user id for each user. If I'm reading the PHP Manual right it's "computationally infeasible" that two different usernames could produce the exact same output after the md5() function has been applied to them.

http://www.faqs.org/rfcs/rfc1321.html

"Computationally infeasible" is not good enough. I need to know for certain whether or not the md5() function may possibly output the exact same encryption for two different usernames.

Is there someone who has experience with the md5() function that can provide additional information?

Thanks.

LordShryku

No, it won't. md5() is a hash, so for one string of letters, it's always going to produce the same hash. change one of those letters, you will get a different hash. It will never produce the same hash for two different words.

Volitics

LordShryku;

Thanks for responding.

That's what I thought. Thanks again for the help.

Volitics

laserlight

Actually, there may be a case where different usernames produce the same hash.

That cant be avoided, since the hash is of a fixed size, while the message of an arbitrary size.

In this case, computationally infeasible should be good enough, for now.
You are arent working with extremely powerful computers, are you?

Weedpacket

So yes; while there are two different messages out there somewhere with the same hash, no-one's found them yet.

superwormy

Its obviously possible that two input will produce the same md5() hash. md5() hashes are always 32 characters long, and only use characters a-z0-9, so theres a finite number of possibilities there.

Meanwhile, the string that you're hashing can ALWAYS be made longer and use a lot more characters, theres an INFINITE number of different strings you could be hashing... some of them have to make the same hash.

But really... why are you hashing usernames? Whats the advantage of comparing a 32 character hash to just the ( probably shorter ) username?

Volitics

I appreciate all of the input.

I'm not hashing usernames for storage purposes. The reason that I'm hashing usernames is to create a 32-character User ID. The hashed User ID is what gets stored in the database - not the username. The username is stored in the MySQL database exactly the way the user inputs it.

The registration script for my web site checks user's usernames to make sure there is not a match. If there's not (a match) then the script registers them.

The registration script (that I'm working on now) processes the username through the md5() function to create the string that I can use for the User ID.

Since each username must be different then the md5() hash (most likely) would be different.

I'm storing the User ID's ($User_ID) in a cookie. I before was having the User ID "auto-increment" - but the first ten or twenty users would get user id's of 1, 2, 3, etc. If anyone looked at their cookie it would look kind of unprofessional to have a user id of "1" or "2". It would make my web site look kind of small and amateurish (which, actually, it is - but I don't want them to know that).

ahundiak

I'd suggest simply using md5(uniqid(rand()));

That way, there will be no relation to the user name.

And make sure you create a unique index on your username field. Otherwise, your site might look a bit amatuerish when you end up with duplicate user names.

LordShryku

Really now. No one has found two message hashes that are the same. And those are full messages, with many combinations of numbers and words. You're just using usernames...
If you honestly think that you will have the billions(give or take a few million) that it will take to produce two same hashes from different usernames, then maybe md5() just isn't powerful enough for you.

pjleonhardt

isnt it something like 6.334 * 10 ^ 49 different possibilities of a md5() output?

pyro

Yes, or close to it, which is obviously a very large number of potential strings. 😉

Weedpacket

Originally posted by pjleonhardt
isnt it something like 6.334 * 10 ^ 49 different possibilities of a md5() output?

2^128, to be exact, or approximately 3.4e38 (32 hex digits == 128 bits). SHA1 produces a 160-bit hash, for possible 1.462e48 hashes.

pjleonhardt

well, i assumed it could be any combination of 0-9 and a-z.. so this leaves us with 36 possibilities in 32 spots..
363636*36.......
or
36³²

or is my logic flawed?

Volitics

El Problemo Solved!

I've decided on a completely different method. Rather than take a chance on two out of a few ga-zillion usernames crashing I wrote my own auto-increment script as follows:	

[code=php]$TableName = "Users";				// Most recently registered $UserID
$Query = "SELECT User_ID FROM $TableName ORDER BY User_ID DESC LIMIT 1"; 
$Result = mysql_db_query ($db_info[dbname], $Query, $db_connection);

while ($Row = mysql_fetch_array ($Result)){
$UserID = $Row["User_ID"] + 1;	// Adds one (1) to it.

}

echo "$UserID<p>"; // Output for testing.

$Query = "INSERT INTO $TableName ( User_ID) VALUES ( '$UserID' )";
if (mysql_db_query ($db_info[dbname], $Query, $db_connection)) {

	$Query = "SELECT User_ID FROM $TableName ORDER BY User_ID DESC LIMIT 1"; 
	$Result = mysql_db_query ($db_info[dbname], $Query, $db_connection);

	while ($Row = mysql_fetch_array ($Result)){
	$UserID = $Row["User_ID"] + 1;

    	echo $UserID; // This $UserID is one more than the one above.
		}

}[/code]

So the first $UserID might be "111111111111", the second "111111111112", the third "111111111113", and so forth all the way to "999999999999" (if I should be that fortunate).

ahundiak

Your new idea needs a bit more work. What if two users try to register at about the same time and they both get the same next id because they both did the original query before the update was done?

You need to either lock the table or check that the original value has not changed when doing the update. Either way is a bit of a pain.

I'd suggest sticking with something like md5(uniqid(rand())); There really is no chance of this duplicating during the lifetime of the universe. Plenty of heavy duty apps follow this technique.

Volitics

Gee. I never thought of that.

The User_ID column in the "Users" table in the MySQL database is set as the primary key.

Using either method the MySQL database would not allow duplicate entries - I don't think.

The PHP manual says that you can insert a rand() function to make the hash even more unique.

// Below per the PHP Manual:
$token = md5(uniqid(""));

echo "$token<p>";

// better, difficult to guess
$better_token = md5(uniqid(rand(""), true));

echo $better_token;

The md5() function, used by itself, creates the exact same hash for the same username each and every time. The above functions create different 32-character random hashes each time with the same username.

I suppose that by even an infintesimally small chance two users should get the same 32-character hash then, since the User_ID column is set as the primary key the MySQL database would let only one of the User_ID's register.

The md5(uniqid(rand())) is a better method I believe.

The "BIGINT" column won't admit a thirty-two character string. Should I use a "BLOB," a "CHAR," or a "TEXT" for the column type?

ahundiak

Use a char(32).

Volitics

Got it. Thanks for the help.

Weedpacket

Originally posted by pjleonhardt
well, i assumed it could be any combination of 0-9 and a-z.. so this leaves us with 36 possibilities in 32 spots..
363636*36.......
or
36³²

or is my logic flawed?

Yep, it's only 0-9a-f; sixteen possibilities. Strictly, it's 128 bits, but they're coded as hex because that's easier to embed in text documents.

pjleonhardt

ahh, its only hex.. gotcha 🙂
so
16^32... still quite a large number