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 479562
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: SHA1 hashed
by Alfman on Tue 5th Jul 2011 05:00 UTC in reply to "SHA1 hashed"
Alfman
Member since:
2011-01-28

siimo,

"SHA1 is a one way hash like MD5. So can't get passwords from it, its pretty much useless to the hacker.

All the google results are pointing to the same hacked paste dump. How do you figure that they are not salted from that?"



It may not be possible to reverse the SHA1 hash *directly*, but it is possible to enumerate password combinations to build a reverse index.

Attackers have databases of enumerated passwords (many gigabytes to terrabytes in size) which are organized to allow one to effectively look up the original text for any SHA1 hash which was enumerated during the generation of the database.

I found an interface to one such database here:
http://www.hashcrack.com/

aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d -> "hello"

Note that you have to hash values without a CR:
> echo -n "hello" | sha1sum

If you have an SHA1 hashed password, it is very likely you can obtain the original password.


edbd1887e772e13c251f688a5f10c1ffbb67960d -> "secretpassword"


The difference with "hash salting" is that each uniquely salted password would need it's own index of cleartext->hash values. So at the very least an attacker would have to generate a new hash database from scratch for each unique salt instead of using a pre-existing database.

However even salting alone is insecure since building the reverse index is feasible using free software. A single desktop processor can try over 10M hashes/sec. That's nearly a trillion per day. A cluster (or running on amazon S3) will crack a salted password in very little time.

The solution is to make the the hash function much slower by applying it recursively. Therefor it takes far more resources to generate the reverse index. However it cannot be too slow otherwise it will effect the legitimate use of the hash.

Edited 2011-07-05 05:01 UTC

Reply Parent Score: 6

RE[2]: SHA1 hashed
by sorpigal on Tue 5th Jul 2011 13:24 in reply to "RE: SHA1 hashed"
sorpigal Member since:
2005-11-02

Informative, but a minor quibble: echo -n suppresses a newline, not a carriage return.

Reply Parent Score: 3

RE[2]: SHA1 hashed
by Soulbender on Tue 5th Jul 2011 15:53 in reply to "RE: SHA1 hashed"
Soulbender Member since:
2005-08-18

However even salting alone is insecure since building the reverse index is feasible using free software.


Actually, no. A sufficiently long salt (say at least 48 bits) makes pre-computed attacks unfeasible.
Of course, combining salting with key-stretching (as in bcrypt) makes it even more unfeasible.

Reply Parent Score: 2

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

Soulbender,

"Actually, no. A sufficiently long salt (say at least 48 bits) makes pre-computed attacks unfeasible.
Of course, combining salting with key-stretching (as in bcrypt) makes it even more unfeasible."

This is not strictly true. You seem to be assuming that the salt is secret, however in a scenario where an attacker gets in through a web application vulnerability, the attacker will have access to the salt and will be able to build the reverse hash indexes based on it.

Consider the practical differences to the attacker who's building a reverse index.

foreach password {
insert hash->password where hash=H(password)
insert hash->password where hash=H(salt+password)
}

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.

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

As I mentioned earlier, applying hash algorithms recursively is an effective way to do this. There are many possible variants of this idea, here are the two most obvious:

H(H(H(H(salt+password))))
H(salt+H(salt+H(salt+H(salt+password))))

Reply Parent Score: 2