Topic: Email activation + PHP + md5

[Canuck]

I was looking at this article

http://www.olate.co.uk/articles/232

regarding email activation of a user.

The user's password is stored in the table using the following code:

$encrypted = md5(md5($password).$salt);

(salt is randomly generated)

To activate the user:

Code: [Select]

$url = 'http://www.olate.com/activate.php?hash='.md5($password).'&stamp='.base64_encode($stamp);

UPDATE users
SET status = 1
WHERE (password = "'.md5($_GET['hash']).'") AND (timestamp = '.base64_decode($_GET['stamp'].')

And he states "Using the md5() and base64_encode() functions, you can irreversibly hash the password and encode the timestamp (so you can get it back again in the processing script)."

Am I missing something? He encrypts the password like so "$encrypted = md5(md5($password).$salt);", I dont understand how using md5 on the $_GET[] variable will match the password in the database...

Thanks

[Mike]

Look at the url.
hash = md5($password)
stamp is the salt (pretty poor salt IMO but meh)

So you end up with md5(hash . stamp) which you can expand to md5(md5(password).salt)

[Canuck]

There is a different function to generate the salt

Code: [Select]

function generate_salt()
{
     // Declare $salt
     $salt = '';

     // And create it with random chars
     for ($i = 0; $i < 3; $i++)
     {
          $salt .= chr(rand(35, 126));
     }
          return $salt;
}


So unless I query the salt from the database from the particular username.... I dont know how else I could decode it.

[JaWiB]

In any case isn't MD5 no longer considered secure?

[Canuck]

>>In any case isn't MD5 no longer considered secure?

I have no idea!

Would this work? I get the time when the user registers, I can encode that in the database, and encode it the URL (I currently just store it without encoding it, in the user table).

I can then decode that, grab the salt from the table for that user, use it on the password, and then activate the user accordingly?

I would also have to use something besides the encoded time in the URL though..

[Mike]

IIRC for every hash from MD5 a corresponding string that will produce that hash is known.

[Canuck]

Well Im not too concerned about security, its more of stopping bots from posting, thats why I have the email validation. I hope that will be enough.

[Steve]

IIRC for every hash from MD5 a corresponding string that will produce that hash is known.

You are correct.

In any case isn't MD5 no longer considered secure?

Some people feel that way because it is from 1991. There are some MD5 reversal tools online, but they work like dictionary hacks. If the password isnt already on file in its real state, the tool cannot reverse the MD5 hash. Personally i dont feel the method itsself is insecure. No matter how strong encryption gets, there is always a way to go back.

[JaWiB]

>If the password isnt already on file in its real state, the tool cannot reverse the MD5 hash.

Well, you might never recover the original password, but if you find another password that produces the same hash, then doesn't it defeat the system?

[Steve]

Not really. You still havent effectively cracked into the persons account. It's like if i send you to the store for an orange, and you come home with an apple, it doesnt count.

[JaWiB]

If somehow I'm able to get your hash, I send the server a password that it computes into an identical hash and gives me access to your account, no?

[Mike]

Not really. You still havent effectively cracked into the persons account. It's like if i send you to the store for an orange, and you come home with an apple, it doesnt count.

RoD, I don't think you understand how hashing works.  As long as the string I give hashes to the same value as the real password then the system doesn't know any different.  Salting the hashes just makes it so you can't lookup a string that hashes to what is stored in the database and use that as the password.

[Steve]

Ohh i see what hes saying now (his last post helped). I'm looking at it from the wrong angle/direction.

[Perspective]

The purpose of a salted hash is to prevent dictionary attacks (pre computing the hashes of an entire dictionary and comparing them against stored hash values). Each user has his own salt, so a dictionary attack isn't possible without pre computing the dictionary n times with each salt.

If you're not really worried about security you could just toss the salt and use a straight hash, otherwise you need the salt to compute the proper hash code for each user.

[Perspective]

>you could just toss the salt and use a straight hash

I feel like getting breakfast at Smitty's all of a sudden.