Jump to content

md5 or sha-1?


rockinaway

Recommended Posts

  • Replies 50
  • Created
  • Last Reply

Top Posters In This Topic

Have some randon string before or after the string password, ex:

 

<?php
$password = sha1(rand(0,1000) . $password);
?>

 

This is what I don't understand. If you have a completely random salt, how do you compare user input of a password string later on? I could understand if the salt is constant, then it could be added after the input is submitted but if the salt is random, there is no way of doing a comparison.

Link to comment
Share on other sites

You can't just concatenate a random string to the front. Salts are used with crypt(). The salt is added to the front of the encrypted version. So, you use the encrypted version to check...like so:

 

<?php
  //How to encrypt it
  //Crypt will add a random salt for you
  //Every time you run crypt, it will return something different (unless you specify the salt)
  $encrypted = crypt($password); 

  //How to check it
  if(!strcmp($encrypted,crypt($password,$encrypted)))
    print 'Success';
  else
    print 'Fail';
?>

 

 

 

Link to comment
Share on other sites

Yeah the random string attached is rather pointless, as it would have to be consistent. if there password is asdf, and we make it 123123_asdf. The next time a hacker tries to access the system it is required of you to use the same salt it would still have to be using 123123_$password. It is a rather moot use.

 

I'm not to sure the double md5 helps either. If someone is trying to brute the password, in order for your system to find a match you need it to double md5 the input. the same word md5'ed twice still has the same outcome. This would however help prevent lookup attacks if the user already compromised the database and can see the encrypted password. This is when double md5'ing would be useful.

Link to comment
Share on other sites

Yeah the random string attached is rather pointless, as it would have to be consistent. if there password is asdf, and we make it 123123_asdf. The next time a hacker tries to access the system it is required of you to use the same salt it would still have to be using 123123_$password. It is a rather moot use.

 

You're supposed to keep the salt secret.

Link to comment
Share on other sites

You're supposed to keep the salt secret.

 

Yes; but my point is lets say the user creates a password 'password'.

 

Programtically we salt 123_ onto the beginning of it and we get 123_password, then encrypt it, and end up with our 32 bit password that we store in the database.

 

If someone tries to brute force it and they enter 'password' into the box when trying to log on as a user, we have to progmatically attach '123_' to the beginning of what they entered so that the encryption will match up.

 

The only place i see a salt being useful is if the database has already been compromised, and the breacher can see the encrypted password.

Link to comment
Share on other sites

Yes, of course -any salting does not prevent brute force attacks. However, if someone is going to try and brute force though your system that adds the salt, then its going to take a hell of a long time. Sure, writing a program to brute force may not - but adding in the requests to an external server will.

 

As for the idea of using the MD5 algorithm twice - i occassionaly see it mentioned that this is infact less secure than a single use of the MD5. I think this tends to be talked about with reference to hash collisions. That said, i've never seen anything which proves this or otherwise - and it certainly seems counter intuitive to me. Anyone have any thoughts on that?

Link to comment
Share on other sites

You're supposed to keep the salt secret.

 

Yes; but my point is lets say the user creates a password 'password'.

 

Programtically we salt 123_ onto the beginning of it and we get 123_password, then encrypt it, and end up with our 32 bit password that we store in the database.

 

If someone tries to brute force it and they enter 'password' into the box when trying to log on as a user, we have to progmatically attach '123_' to the beginning of what they entered so that the encryption will match up.

 

The only place i see a salt being useful is if the database has already been compromised, and the breacher can see the encrypted password.

 

I don't think you understand salting. It's supposed to protect brute forcing if you have the hash. If you add, say a 30 char long salt to the beginning, then nobody will have enough computational power to brute force within their life span (as long as the salt remains secret). To protect your login form, just restrict the number of failed login attempts and block the account for a fixed amount of time. Then it'll take a long time to brute force through your login form as well.

Link to comment
Share on other sites

As currently I am just using the md5() hash, that is what I have always used. But I was just reading up on it and then sha-1 turned up.

 

I don't think md5'ing several times has any point to it, it will just keep doing the same thing again and again, and could prove worse?

Link to comment
Share on other sites

The point of using the md5() hash twice is the same as salting - if someone has the hash, then brute force is harder and rainbow tables are useless. As I mentioned earlier however, there appears to be some debate as to wether it's a good idea. I'd recommend adding a salt anyway.

Link to comment
Share on other sites

So this salt would be the same for every password hashed?

 

It could be, but it could also be generated dynamically. You'll just have to ensure that it's always the same for the same password, otherwise you cannot compare it again when a user enters a password.

Link to comment
Share on other sites

I don't think double MD5 can cause any problem at all ...

 

123 to 202cb962ac59075b964b07152d234b70

202cb962ac59075b964b07152d234b70 to d9b1d7db4cd6e70935368a1efb10e377

 

Good luck cracking that ... hehe

 

That's really poor encryption. The idea is about string length. Longer strings take longer time to crack. Seeing as a brute-force searching algorithm would run at O(n!), if there is a fairly long salt at the front of the actual password in the hash, cracking the password within reasonable time would be impossible. When brute-forcing your string one would just do md5(md5($string)); instead of md5($string);.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • 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.