md5 or sha-1?

[rockinaway]

Which type should I use for my passwords?

[rhodesa]

I use crypt()...but I don't know which is better

[discomatt]

SHA1 has less collisions, and rainbow tables aren't quite as complete.

 

As long as you salt properly, both work very well. I would personally use SHA1, if the increased bitlength isn't an issue.

[Daniel0]

I'd probably go with something like sha-256:

 

hash('sha256', $string);

[rockinaway]

I didn't know sha256 was possible :S

 

 

And what do you mean by salting properly?

[conker87]

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

 

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

[haku]

I didn't know sha-256 was possible either.

 

crypt() isn't so good, as it can be decrypted. sha1 and md5 are both one-way, making them more secure.

[rhodesa]

How can crypt() be decrypted?

[maexus]

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.

[drisate]

Just use

<?php

$password=md5(md5($_POST[password]));

if ($password==$pass_in_db){
echo "The pass is teh same";
}else{
echo "The pass is not the same";
}

?>

 

Double MD5 is perfect :-)

[rhodesa]

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';
?>

 

 

 

[drewbee]

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.

[Daniel0]

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.

[drewbee]

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.

[GingerRobot]

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?

[Daniel0]

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.

[rockinaway]

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?

[GingerRobot]

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.

[rockinaway]

Even with an md5 I should add a salt? Could this salt be anything?

[GingerRobot]

Yes. It's best you make the salt of a reasonable length and of mixed characters.

[rockinaway]

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

[Daniel0]

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.

[haku]

How can crypt() be decrypted?

 

My bad. I thought I had read of decrypt(), but I had actually read of mcrypt_decrypt(). crypt() is one way.

[drisate]

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

 

123 to 202cb962ac59075b964b07152d234b70

202cb962ac59075b964b07152d234b70 to d9b1d7db4cd6e70935368a1efb10e377

 

Good luck cracking that ... hehe

 

[Daniel0]

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