OSNews

Soulbender,

"False. Salting significantly increases the time and complexity of creating the tables. See below.
If it didnt add anything significant it wouldn't be recommended practice."

That's not precisely what I said, I asked specifically about forward hashing complexity. I did edit my post by adding "time" in parens, but I guess it was too late.


I'd like to enter into evidence the following PHP example (apologize in advance for formatting bugs):

function NullHash($password, $salt) {
return $salt.$password.$salt;
}
function Unsalted($password, $salt) {
return hash('sha256', $password);
}
function SimpleSalt($password, $salt) {
return hash('sha256', $salt.$password.$salt);
}

function HMACSalt($password, $salt) {
return hash_hmac('sha256', $password, $salt);
}


function RunTest($function, $name) {
$password = 'superbadass';
$salt = 'kk222929';
$time = microtime(true);
for($i=0; $i<1000000; $i++) {
$function($password, $salt);
}
$time = microtime(true) - $time;

printf(" %10s %10.3s\n",$name,$time);
}

for($trial=0; $trial<3; $trial++) {
print "\nTrial $trial\n";
RunTest(NullHash, 'NullHash');
RunTest(Unsalted, 'Unsalted');
RunTest(SimpleSalt, 'SimpleSalt');
RunTest(HMACSalt, 'HMACSalt');
}




The output for me is as follows:

Trial 2
NullHash 0.7
Unsalted 1.9
SimpleSalt 2.1
HMACSalt 4.4


Now, PHP is a terrible choice for doing this sort of benchmark due to high string overhead. But the prototype was quick and I believe my point stands.

The unsalted and simple salt algorithms have nearly the same forward hashing performance. The HMAC algorithm (which calls the sha hash twice under the hood) is slower by roughly a factor of two.

This shows that forward hashing is not significantly affected by adding salt. If you buy all this, then the answer to my second assertion is true.



"True but you would need one rainbow table for each possible salt. The longer the salt, the more tables needed. This is why salting defeats rainbow tables in practice."

I wasn't really talking about "rainbow tables" specifically, I was talking about indexes like the one in the link I provided.

A rainbow table discards information in a time/space tradeoff and is therefor a subset of a more complete index. Whether or not they are effected by salt probably depends on the salting algorithm and the way in which the rainbow tables are generated. But this does not affect a dictionary permutation attack.

Soulbender,

I did some research on bcrypt. I guess I should have realized that you were talking about a replacement for the original unix crypt, which is surprisingly still very common.

bcrypt is designed to impede brute force scanning by slowing down forward hash computation. It also uses a large salt size, unlike crypt which is embarrassingly small with only 4096 possibilities.

http://www.openbsd.org/papers/bcrypt-paper.ps
"Bcrypt uses a 128bit salt and encrypts a 192bit magic value. It takes advantage of the expensive key setup in eksblowfish"

It repeatedly encrypts the cleartext 64 times and has a specifiable cost parameter to slow down the hashing further.

Along the way I came across another "scrypt" which is said to be better than bcrypt on account of being not only computationally intense, but also by having much higher ram/state requirements. This is said to make custom ASIC processor design that much more difficult, since these often have limited states.

I think both of these would be fine for password hashing.

I still consider H(salt+password) to be vulnerable against moderately resourceful attackers since forward hashing is way too quick.