SHA1 has been broken according to this blog (Bruce Schneier)?  Looks interesting although there are little details other than a recent paper on a collision which this attacks supposedly builds upon.  Found this blog post on Raymond Chen's blog where I also saw, of all people, Skywing.

uh oh. If I were storing any sensative data sha-1 woulda been my choice... guess it is still tougher than md5 though.

[quote author=quasi-modo link=topic=10578.msg99931#msg99931 date=1108522241]
uh oh. If I were storing any sensative data sha-1 woulda been my choice... guess it is still tougher than md5 though.
[/quote]

I'd worry if anybody stored sensitive data in sha-1, considering that one of the characteristics of sha-1 is that you can't convert it back to the original :P

Ah, you beat me to that comment!

What is the point of SHA-1 if you can't reverse it back to the original info?!

It's designed as a one-way hash.  You can encrypt passwords and not worry that Blizzard are goign to turn them back into regular passwords.  It can also be added to an encrypted message to ensure that the message hasn't been tampered with.

What about avalibility?  ;)

I still don't understand the point of something you can reverse

[quote author=CrAz3D link=topic=10578.msg99950#msg99950 date=1108526809]
What about avalibility?  ;)

I still don't understand the point of something you can reverse
[/quote]

Sorry, I edited my post, got rid of that nonsense (fine, valuble but irrelevant information).  Read it again, I explained it better.

What is the point of the password thing?  Do you just check to see the the SHA-1 of the password that is sent to BNET is same as what they compare it to?

[quote author=CrAz3D link=topic=10578.msg99952#msg99952 date=1108527702]
What is the point of the password thing?  Do you just check to see the the SHA-1 of the password that is sent to BNET is same as what they compare it to?
[/quote]

Battle.net uses double-sha1's password.  This is what happens (for pre-war3 products):

When you create your account, you send them the SHA1 version of the password.  That password is stored by Battle.net.

When you log in, you SHA1 your password, alone.  Then you SHA1 your password along with the client and server token.  The server does the same thing, also hashing your SHA1'd password along with the client/server tokens.  Then you send your double-sha1'd password, where it is compared to the server's version.

OH!, k, makes more sense I guess.

[quote author=iago link=topic=10578.msg99939#msg99939 date=1108525641]
[quote author=quasi-modo link=topic=10578.msg99931#msg99931 date=1108522241]
uh oh. If I were storing any sensative data sha-1 woulda been my choice... guess it is still tougher than md5 though.
[/quote]

I'd worry if anybody stored sensitive data in sha-1, considering that one of the characteristics of sha-1 is that you can't convert it back to the original :P
[/quote] It is great for dbs. You encrypt passwords / credit card numbers. It is not meant to be decrypted really. You encrypt an entry and match it. Ideally you would salt the password feild / whatever, with a userid feild or something.

Keep in mind: Even if you are on a server that has never been hacked into and the admins keep up with updates the admins can still see the passwords / credit card numbers / whatever else you are keeping. So you should encrypt everything you do not want anyone to see. If you use a 2 way algorythm your key has to be stored somewhere and the admin will be able to use it to decrypt the stuff so you are back where you started.

ps: If passwords, ssns, and credit card numbers, are encrypted in sha-1 (used for identification purposes) then sensative data is being stored in sha-1 correct?

It's not being "stored" 

tr.v. stored, stor·ing, stores
  1. To reserve or put away for future use.

You can't use it one it's hashed.

Anyway, the problem with SHA-1 likely won't affect its security for storing passwords and such; it will affect SHA-1's that are being used to verify documents

[quote author=iago link=topic=10578.msg100460#msg100460 date=1108769837]
It's not being "stored" 

tr.v. stored, stor·ing, stores
  1. To reserve or put away for future use.

You can't use it one it's hashed.
[/quote] That is correct. I was just 'going by a different deffinition' I guess.
I mean once it is hashed it is not useless.... The user types a pass that then gets encrypted and then you can match the two up and then the user entered the correct pass if they match. But I agree that no data can be gathered from the hashed values because sha-1 is a one way encryption algorythm.

[quote author=quasi-modo link=topic=10578.msg100455#msg100455 date=1108769006]
It is great for dbs. You encrypt passwords / credit card numbers. It is not meant to be decrypted really.
[/quote]
What would be the purpose of SHA-1'ing a credit card number, would they not need it for billing purposes?

[quote author=j0k3r link=topic=10578.msg100517#msg100517 date=1108824403]
[quote author=quasi-modo link=topic=10578.msg100455#msg100455 date=1108769006]
It is great for dbs. You encrypt passwords / credit card numbers. It is not meant to be decrypted really.
[/quote]
What would be the purpose of SHA-1'ing a credit card number, would they not need it for billing purposes?
[/quote] Some sites use it for identification purposes. Same as a social. For instnace my online banking uses my social. Paypal can use a credit card number.

Tthe attack that has been found on SHA-1 wouldn't enable anyone to retrieve plaintext from the hash.

What the attack does is to allow you to find collisions more quickly, which makes a birthday attack possible.

[quote author=Arta[vL] link=topic=10578.msg100569#msg100569 date=1108847244]
Tthe attack that has been found on SHA-1 wouldn't enable anyone to retrieve plaintext from the hash.

What the attack does is to allow you to find collisions more quickly, which makes a birthday attack possible.
[/quote] Well it does not really needs to let you retrieve text... it just needs to let you login as someone else.

I don't see how this attack makes that more likely than it was before?

[quote author=Arta[vL] link=topic=10578.msg101178#msg101178 date=1109169383]
I don't see how this attack makes that more likely than it was before?
[/quote]  If sha-1 is vulnerable (I do not know how this attack works exactly), and sha-1 is what the passwords are encrypted in, then if sha-1 were broken would it not allow you to login as someone else more easily?

Birthday is no longer really a threat if you salt the password feild with an id feild or something.... it would turn into a conventional brute force at that point.

I do not know much about what this new attack does, only what was in the op. All I know is md5 was broken a long time ago but it is still pretty seucre and still widely used.

The attack makes it considerably easier (2[sup]69[/sup] instead of 2[sup]80[/sup]) to find plaintexts that cause collisions. That is, given a plaintext P[sub]1[/sub], it is now much easier to find a plaintext P[sub]2[/sub] such that SHA1(P[sub]1[/sub]) == SHA1(P[sub]2[/sub]).

That's why this vulnerability facilitates a birthday attack. A typical example might be to take a document (for example, a contract), D[sub]1[/sub], that is signed using SHA1 to ensure that it has not been modified in transit. If Mallory wants to tamper with this document, they could do it by making the change they need, and then making lots of small, imperceptible changes (for example adding spaces), until they had a document D[sub]2[/sub], such that H(D[sub]1[/sub]) == H(D[sub]2[/sub]). Mallory can then send this document to the victim, and claim that it is the original. The victim will check the hashes, which will be the same, and will not be aware of the changes made.

It's a simplistic example but it illustrates the most serious problem raised by this vulnerability.

It does also make it easier to brute force the plaintext used to generate hashes, but 2[sup]69[/sup] is still a lot of work, so that shouldn't be a problem in the immediate future.

[quote author=Arta[vL] link=topic=10578.msg101271#msg101271 date=1109200722]
The attack makes it considerably easier (2[sup]69[/sup] instead of 2[sup]80[/sup]) to find plaintexts that cause collisions. That is, given a plaintext P[sub]1[/sub], it is now much easier to find a plaintext P[sub]2[/sub] such that SHA1(P[sub]1[/sub]) == SHA1(P[sub]2[/sub]).

That's why this vulnerability facilitates a birthday attack. A typical example might be to take a document (for example, a contract), D[sub]1[/sub], that is signed using SHA1 to ensure that it has not been modified in transit. If Mallory wants to tamper with this document, they could do it by making the change they need, and then making lots of small, imperceptible changes (for example adding spaces), until they had a document D[sub]2[/sub], such that H(D[sub]1[/sub]) == H(D[sub]2[/sub]). Mallory can then send this document to the victim, and claim that it is the original. The victim will check the hashes, which will be the same, and will not be aware of the changes made.

It's a simplistic example but it illustrates the most serious problem raised by this vulnerability.

It does also make it easier to brute force the plaintext used to generate hashes, but 2[sup]69[/sup] is still a lot of work, so that shouldn't be a problem in the immediate future.
[/quote]

Even the example you gave it highly unlikely.  I think the point is that once you find a small hole in a hasing algorithm pretty soon someone is going to find a bigger hole.  Generally, the security of a hashing algorithm doesn't increase but decreases over time, however these kind of exploits only make it decrease quicker.

Just a picky little note, this isn't an "exploit", it's a vulnerability or weakness.

[quote author=iago link=topic=10578.msg101514#msg101514 date=1109304586]
Just a picky little note, this isn't an "exploit", it's a vulnerability or weakness.
[/quote]

Yes, good catch :)