hashing

[ohdang888]

simple question...

 

is there a benefit to hashing something multiple times?

for example...is md5(sha1(md5($code))) more secure than just md5($code)

 

????

[Fadion]

Each of those hashing algorithms can be un-hashed only by a technique called rainbow tables. Using md5(sha1()) will surely make it quite impossible to cr@ck, but the same is for password+salt hashing. Basically:

 

<?php
$pass = 'phpfreaks';
$salt = rand(1000, 9999);
$hash = sha1($pass . $salt);
//store the password and salt in the database
?>

[Mr_jmm]

Yes it will be harder to break but imo it's not strictly worth it except it takes bugger all to code and can't do any harm. Use SHA1 with a salt.

 

Something like

 

$pwd = sha1( $foo .$salt .$bar )

 

EDIT: got beaten to the post!

[Mchl]

Or use hash() for even more secure algorithms (and don't forget salting)

[knowj]

Yes and No.

 

Yes:

If someone gained access to your database and used a lookup table on it the chance of them getting a users password is greatly decreased. But if someone has access to your database they generally have access to your ftp and your code.

 

No.

One of the most common hacks if a dictionary lookup brute force attack running through combinations of passwords trying to hack a users account. A system is only as secure as the users that use it.

 

Having a salted md5 e.g. $password = md5($password.'mys4lt'); is usually more than enough to ensure users passwords are secure within a database. To increase security you should enforce secure password 8+ characters containing alphanumeric and special characters.

 

 

When developing a system you need to consider the value of the data you are storing the more valuable the greater the risk. If you are storing passwords for a my little pony fan club the chance of someone/a group of people spending hours/days of their life trying to get user data is slim to none. If however you are writing an application for a bank people will spend years trying to break the systems you put in place to protect your users/data. This it where you would need to build layers of security but even then I doubt you would hash a hash. If it would benefit an encryption algorithm to go further with its encryption process the mathematician would have built it in when he developed it. I'm not however saying algorithms are perfect anything can reverse engineered with enough time/effort/cpu cycles.

[knowj]

Yes it will be harder to break but imo it's not strictly worth it except it takes bugger all to code and can't do any harm. Use SHA1 with a salt.

 

Something like

 

$pwd = sha1( $foo .$salt .$bar )

 

EDIT: got beaten to the post!

 

It starts as bugger all to code but every time you need to compare the hash you need to prep every comparison which becomes a pain especially when your system grows (even worse if your writing procedural code *cringes*)

[Fadion]

Or use hash() for even more secure algorithms (and don't forget salting)

 

From what I've read, sha1() may have mathematical flows so using the sha-2 hashing algorithms (sha256, sha512) should be preferable. That should be theoretical anyway as I'm still sure that the only way to decrypt them is by rainbow tables. At least hash() offers the possibility to use sha256 and sha512, so good point

 

If someone gained access to your database and used a lookup table on it the chance of them getting a users password is greatly decreased. But if someone has access to your database they generally have access to your ftp and your code.

 

Having access to database data doesn't mean knowing the password. Sql injections are the case.

 

I'm not however saying algorithms are perfect anything can reverse engineered with enough time/effort/cpu cycles.

 

Hashing a password with a long salt (15 chars for example) would need a lifetime to decrypt, no matter what hardware you have. The only possible problem would be algorithms flow, but even them are being redesigned, so the possibilities are vague.

[waynew]

As stated in this thread:

 

http://www.phpfreaks.com/forums/index.php/topic,214543.0.html

 

Doing what you talked about may increase the chances of a collision. A simple salt like:

 

<?php

$hashed = sha1("jhj678928bbdhbedhbedhbhjiioiwoei".$unhashed_pass."laopwhydeg32!&nsh");

?>

 

Will work a doozy!

[ohdang888]

i've been using just md5()

 

what's a salt?

 

 

and if i stored that raw number in a database, can't the hackers get that? (assuming they would see my tables)

[Fadion]

A salt is a randomly generated string that is appended to the original password. Is not a function parameter or something, just a name assigned to the technique. It is used to alter the original password so it can't be found by brute force/dictionary:

 

<?php
$pass = 'mypass';
echo md5($pass); //will print the hash of 'mypass'
$salt = 'random123456data';
echo md5($pass . $salt); //will print the hash of 'mypassrandom123456data'
echo md5($salt . $pass); //will print the hash of 'random123456datamypass'
?>

[slapdashgrim]

but if you do use salt how do you write a login script?

how would the system know the random number?

[ohdang888]

so the column 'password' would have the md5 of the combined salt and password. and the `salt` would just have the random number, unsalted?

 

[Fadion]

but if you do use salt how do you write a login script?

how would the system know the random number?

 

You can alter your users table to fit in a "salt" column, which holds the salt. For increased security, if someone finds both the salt and the pass, you can even use a salt like this:

 

<?php
$pass = 'phpfreaks';
$salt = 'random12345|stillsomerandom';
list($salt1, $salt2) = explode('|', $salt); //divide the string in to sub strings by the | character
$hash = sha1($salt2 . $pass . $salt1);
?>

 

Just have your own *secret* technique to be sure no one will get the password. Even though, being so much skeptic is overwhelming in my opinion as people won't come and loose time randomly in small sites. Maybe a static salt (one salt for everybody) can provide the right security.

 

so the column 'password' would have the md5 of the combined salt and password. and the `salt` would just have the random number, unsalted?

 

Yes that's the idea. The password fields is the hash of password+salt, while the salt is stored in a different field.

[JasonLewis]

A salt does not have to be random, it can be a set string by the administrator. You could use "jkjauNyowey" as your salt if you wanted to.

[Mchl]

Or it can be for example user's e-mail written backwards.

This way you don't have a column called 'salt' in your users table (security through obscurity, I know)

 

(and user has to regenrate password each time he/she changes email)