MD5 VS SHA1 VS AES_ENCRYPT?

[nuttycoder]

I've been reading up on password encryption and I've always used MD5 but seems like its not very secure any more, so now am wondering what's better MD5 VS SHA1 VS AES_ENCRYPT?

 

AES_ENCRYPT seems like a secure way to encrypt passwords but being able to decrypt them seems a bit cautious.

 

Any one any thought of the best way to encrypt passwords?

[Trium918]

MD5 with the help of SALT.

[Psycho]

For passwords you want to use a HASH not an encryption. MD5 and SHA1 are hashes and, technically, cannot be reversed. The use of a salt as mentioned above will further secure the hash. You would use an encryption for something like a CC number that you would have to unencrypt later when processing a new order.

[nuttycoder]

Thanks for your thoughts guys.

 

I always thought of MD5 as encryption not hashes, I'm now aware there actually hashes useful to know 

 

What is this salt?

[derwert]

There is no definitive way to salt a hash. Basically what is done is the script will make some changes to the hash so it's more than just md5('password').

 

Some ways would be to generate a random string for each user; they would call this a salt and store it.

Now when a users password is stored they would use the salt when generating the hash, such as md5('password'.md5('salt')); or md5(md5('password').md5('salt'));

 

This will ensure that the password is long and it will also cause the use of rainbow tables against the hash to be useless.

 

Now if someone is able to get the hash and salt they can still do a dictionary attack and also a brute force attack against the hash; so the only extra protection it's adding to it is by not allowing the use of rainbow tables.

 

If you were to enforce a password policy to ensure passwords are long and use upper and lowercase characters, along with symbols and numbers then this will cause a dictionary attack to fail and also would make a brute force attack to take an unreal amount of time.

 

This is all a precaution in case the information gets leaked one way or another.

 

Also if you don't have any type of limiter for the number of failed logins on your script then the use of strong passwords would cause a brute force attack to fail in this sense also.

[nuttycoder]

Thanks very much very informative I'll have to look into implementing a salt with a hash.

[phpknight]

FYI, Apress has a PHP Pro Security Book that is pretty good for this sort of thing and other good security advice.  I wouldn't just try without reading that first.

[nuttycoder]

Thanks for that, found the book on Amazon so I'll place an order for it.

[kratsg]

The idea is simple, a rainbow table has all predefined encryptions, and if they get your salt, then they can add it to all the words, re-encrypt and go through it all.

 

If you have users on the site, give each one of them a random generated salt (that's stored in their user database row so you can call it to check on the password when they log in). Now, because each one is a random salt, that means it takes more time to check each person by re-modifying the table for every single user, waaaay too much time. Also, SHA1 is slightly slower than MD5 and is better, slower=better. Why? It takes even more time for the hacker to encrypt.

[derwert]

The idea is simple, a rainbow table has all predefined encryptions, and if they get your salt, then they can add it to all the words, re-encrypt and go through it all.

 

The way you explain it is incorrect. Rainbow tables are pre-generated hash tables of a given character set/length for a specific encryption type.

The way you're saying it makes it to be a simple task; it's not. Generating rainbow tables is a very lengthy process.

 

 

Also, SHA1 is slightly slower than MD5 and is better, slower=better.

 

Your logic is flawed; difference between the two functions are so minimal that it would hardly have a effect. That is no excuse to allow for weak passwords. If someone has a weak password it won't matter what hash algorithm is used, the password will get cracked.

 

As I said before, a strong password is more important.

[phpknight]

About the book again, about half the book relates to server issues, but the second half is very good for PHP code.

[kratsg]

derwert, I don't base my idea on how strong a password is, but how much time it takes on the hacker's side (if you run the SHA1 function over 500 million times, it is quite clear how much slower it is compared to the MD5). Yeah, the rainbow table is a big huge table, of over 5 billion encryptions (using MD5, SHA1, etc...) If a hacker gets your salt, they "probably" won't know how you added the salt, such as if it was hashed first, then added to the front/end/both or not hashed, etc... If, for example, they knew you added it to the beginning (un-hashed), they just take the salt, add it to the beginning of all their rainbow table words, re-encrypt (using a hash) which takes more time. This is why you want a different salt per person, and why it's not just good to have a strong password, but REALLY make it take time.

[nuttycoder]

About the book again, about half the book relates to server issues, but the second half is very good for PHP code.

 

Yeah some reviews I've read say the same thing I think an understanding of both server and php is useful.

[nuttycoder]

Your logic is flawed; difference between the two functions are so minimal that it would hardly have a effect. That is no excuse to allow for weak passwords. If someone has a weak password it won't matter what hash algorithm is used, the password will get cracked.

 

As I said before, a strong password is more important.

 

So as long as you force strong passwords its not that important weather you use md5 or sha? as long as you use 1 of them.

[only one]

For passwords you want to use a HASH not an encryption. MD5 and SHA1 are hashes and, technically, cannot be reversed. The use of a salt as mentioned above will further secure the hash. You would use an encryption for something like a CC number that you would have to unencrypt later when processing a new order.

 

http://www.md5.rednoize.com/

[MadTechie]

For passwords you want to use a HASH not an encryption. MD5 and SHA1 are hashes and, technically, cannot be reversed. The use of a salt as mentioned above will further secure the hash. You would use an encryption for something like a CC number that you would have to unencrypt later when processing a new order.

 

http://www.md5.rednoize.com/

 

mjdamato, is correct and that link is just a rainbow table (which is usless to any site with salt)...

the fact is if you want to be secure with MD5 then add SALT.. as for someone adding you salt to their rainbow table.. well thats easy to fix.. when the user signs up.. generate a random code.. this is their thats users own salt code..

 

as for a compare of one way encryptions (HASHing) Instead of saying SHA1 is a better than MD5, i'll just say that SHA1 is slower than MD5 but it generates a larger digest size that makes it stronger against brute force attacks...

personally i still use MD5 with SALT (every users has their own salt)

[Daniel0]

You could use the hash() function to choose between a variety of different hashing algorithms. From what I remember, sha256 should be just as fast (or faster) than md5.

[MadTechie]

SHA256, is better than SHA1 and MD5, as MD5 has the Collision problem and SHA1 has (a kinda Collision problem), where as SHA256 doesn't (well there's no guarantee).. so yeah much better for security.. but speed.. well you can't run it from an SQL query..(who cares).. i think its a little slower that SHA1 (but i am not sure about that)..

[Daniel0]

I did some testing... It seems that I was incorrect and that sha256 is slower than md5. Here are the results of all the algorithms by hash():

 

crc32           0.001149ms
crc32b          0.001227ms
adler32         0.001346ms
md4             0.001427ms
md5             0.001443ms
sha1            0.001751ms
tiger160,3      0.002028ms
tiger128,3      0.002068ms
tiger192,3      0.002098ms
sha256          0.002297ms
tiger192,4      0.002326ms
tiger160,4      0.002328ms
ripemd256       0.002389ms
ripemd128       0.002391ms
ripemd160       0.002510ms
ripemd320       0.002560ms
haval224,3      0.002641ms
haval128,3      0.002678ms
haval192,3      0.002682ms
haval160,3      0.002695ms
haval256,3      0.002759ms
tiger128,4      0.002893ms
haval160,4      0.003088ms
haval256,4      0.003107ms
haval128,4      0.003120ms
haval192,4      0.003130ms
haval224,4      0.003176ms
haval128,5      0.003286ms
haval256,5      0.003313ms
haval192,5      0.003317ms
haval224,5      0.003346ms
haval160,5      0.003350ms
whirlpool       0.004696ms
snefru          0.005016ms
gost            0.005208ms
sha384          0.006023ms
sha512          0.006140ms
md2             0.027228ms

Total execution time 13.424612s

(ordered ascendingly by speed)

 

The code I used is:

<?php
set_time_limit(0);

class Timer
{
private $start_time;

function __construct()
{
	$this->start_time = microtime();
}

function get_time()
{
	$start_time	= explode(' ', $this->start_time);
	$stop_time	= explode(' ', microtime());

	$start_time	= $start_time[0] + $start_time[1];
	$stop_time	= $stop_time[0] + $stop_time[1];

	return $stop_time - $start_time;
}
}

$global_timer = new Timer();

$string = "ASj¤%&sld7%¤ASJf/&83sjd";
$algorithms = hash_algos();

function get_time_hash($algorithm, $string, $times)
{
$timer = new Timer();

for($i=0; $i<=$times; $i++)
{
	hash($algorithm, $string);
}

$end_time = $timer->get_time();
$average_time = $end_time / $times;

return $average_time;
}

$times = array();
foreach($algorithms as $algorithm)
{
$times[$algorithm] = get_time_hash($algorithm, $string, 100000);
}

asort($times);

foreach($times as $algorithm => $time)
{
echo sprintf("%-15s %.6fms\n", $algorithm, $time*1000);
}

echo "\nTotal execution time ", sprintf('%.6f', $global_timer->get_time()), 's';
?>

[dbo]

Put an additional policy on whatever route you go. X failed attempts in Y amount of time locks your account for Z minutes. Could also log repeated failures at a given IP address and lock based on that.

 

At the end of the day it's all about security in layers and if security truly is a big concern for the said application you should implement multiple layers.

[MadTechie]

true also, an old saying "it doesn't matter how strong the front door is, if the windows left open"

you are the weakest link.. good bye

[cooldude832]

Who cares about micro seconds, you are running 1 encryption at most on a page. 

[dbo]

I believe it was illustrated to show the time it takes for a hacker to call the function. A brute force script could considerably be bogged down over time with certain functions. I wouldn't really consider this a line of defense... but I think that's why it was discussed.

[MadTechie]

Its just a way of working out the pro's and con's.. yeah microseconds.. running once isn't a problem... but you may not run it once.. you may need to use it on a database with millions records..  and that may only be part of a routine thats run hourly.. in that case.. your at the point of security vs usability or even durability.. without knowing exactly what its going to be used for we can only look at the pro's and cons

[Daniel0]

Who cares about micro seconds, you are running 1 encryption at most on a page. 

 

FYI PHP can be used for other things than requests through a web server. See the post above mine.