Linked by Thom Holwerda on Mon 4th Jul 2011 21:43 UTC
Apple So, Anonymous, under the guise of its AntiSec campaign, has hacked an Apple server, got access to 27 administrator usernames and passwords, and put them on Pastebin. Is it time to panic? Is it time to point and laugh at Apple? Is it time to stop using iTunes? Not really - this is a small hack that will cause little to no damage.
Thread beginning with comment 479630
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: SHA1 hashed
by Soulbender on Tue 5th Jul 2011 21:41 UTC in reply to "RE[5]: SHA1 hashed"
Soulbender
Member since:
2005-08-18

A reverse hash index can be generated for plain password hashing (as evidenced by the link above). True/false?


Obviously true.

The salting doesn't add significantly to the complexity for forward hashing. True/false?


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.

A reverse hash index can be generated for salted passwords in the same way it can be generated for unsalted passwords.


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 looked it up, but it's a file encryption utility and I'm not really clear about exactly you wanted me to look at.


Oh right, there are more than one "bcrypt".
http://en.wikipedia.org/wiki/Bcrypt

Reply Parent Score: 2

RE[7]: SHA1 hashed
by Alfman on Tue 5th Jul 2011 22:38 in reply to "RE[6]: SHA1 hashed"
Alfman Member since:
2011-01-28

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.

Reply Parent Score: 2

RE[7]: SHA1 hashed
by Alfman on Thu 7th Jul 2011 03:40 in reply to "RE[6]: SHA1 hashed"
Alfman Member since:
2011-01-28

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.

Reply Parent Score: 2