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 479620
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: SHA1 hashed
by Soulbender on Tue 5th Jul 2011 20:22 UTC in reply to "RE[3]: SHA1 hashed"
Soulbender
Member since:
2005-08-18

Salting alone does not create the computational complexity required to foil a permutation attack. In fact it's doubtful even to increase the complexity by a factor of 2.


You're disagreeing with what most cryptographers say.

What is needed is a way to increase forward hashing complexity such that building an index becomes prohibitively expensive and time consuming.


Look at bcrypt. it does what I presume you're after.

Reply Parent Score: 2

RE[5]: SHA1 hashed
by Alfman on Tue 5th Jul 2011 21:31 in reply to "RE[4]: SHA1 hashed"
Alfman Member since:
2011-01-28

"You're disagreeing with what most cryptographers say."

What specifically makes you say that? I have a strong background in cryptography, but I don't think this is necessary to understand why salting doesn't preclude a reverse permutation attack.

I assert:

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

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

3. A reverse hash index can be generated for salted passwords in the same way it can be generated for unsalted passwords. True/false?

If any of these are false, please explain why you think so.


"Look at bcrypt. it does what I presume you're after."

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.

I'm not "after" anything. Just pointing out that H(salt+password) is vulnerable to the same dictionary type attacks as H(password)

If someone were to ask me, I'd advice them to use an SHA2 HMAC for salting with no less than 1K iterations. 10K iterations would be better (and still only take 1ms to compute at login).

If a permutation attack previously took 2 days on a given cluster, it would now take 20,000 days (or 56 years) on the same cluster.


Of course, we're assuming the attackers even care about the passwords, which they may not since they've already obtained elevated privileges by this point.

Edited 2011-07-05 21:36 UTC

Reply Parent Score: 2

RE[6]: SHA1 hashed
by Soulbender on Tue 5th Jul 2011 21:41 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