News - Hackers expose 450,000 Yahoo accounts

[HEXUS]

Gmail, AOL, Hotmail and MSN accounts and others also compromised.

Read more.

[GoNz0]

oh joy...

[cameronlite]

Another nail in the Yahoo coffin.

[Hicks12]

Have i missed something or has this piece of turd group actually released the details in full (i.e not with half of it blurred, did you add this? ). If they did just throw it out well they will end up with a swift punch in the face if i ever meet them, im fed up with little groups like this that think its cool or they're doing people a favour, they arent doing anything good... a wake up call yeah flipping right, if you wanted to give yahoo a wake up call you would have sent them all these details NOT thrown them on the web to hurt CONSUMERS/THE FRACKING PUBLIC.

These people are bloody retards, oh yeah lets gain access to peoples accounts and credit details and release them to public to shove it to the big corporations, instead they make hassle for the public and have basically got spam bots and other **** things selling their credit details etc.

never signed up with yahoo so shouldnt effected but still makes my blood boil, flipping pricks.

[watercooled]

It's completely laughable and unacceptable that any company should hold passwords in plaintext, let alone one as huge as Yahoo. It's not exactly rocket science!

[GoNz0]

my email wasnt on it, and yes emailassword.

best to follow the link in the pic and check if your one of them.

and yes the day i meet someone who admits to releasing stuff like this will get a thumb in each eye.

[mtyson]

The user : pass details were published in full in a big plain text list on their web site. No details were obfuscated by the hackers.

[watercooled]

It's currently down due to high traffic so can't check. Doubt I'll be on it but not a problem to change some passwords anyway...

[CAT-THE-FIFTH]

Domains affected:

Domains
1. Yahoo.com (137,559)
2. Gmail.com (106,873)
3. Hotmail.com (55,148)
4. Aol.com (25,521)
5. Comcast.net (8,536)
6. Msn.com (6,395)
7. Sbcglobal.net (5,193)
8. Live.com (4,313)
9. Verizon.net (3,029)
10. Bellsouth.net (2,847)
11. Cox.net (2,260)
12. Yahoo.co.in (2,133)
13. Ymail.com (2,077)
14. Hotmail.co.uk (2,028)
15. Earthlink.net (1,943)
16. Yahoo.co.uk (1,828)
17. Aim.com (1,611)
18. Charter.net (1,436)
19. Att.net (1,372)
20. Mac.com (1,146)

[watercooled]

Yeah that is pretty scary, what's Yahoo doing with plaintext Gmail/Hotmail passwords? Unless I've misunderstood...

[CAT-THE-FIFTH]

It seems to be connected with something called Yahoo Voices:

http://mashable.com/2012/07/12/yahoo-voices-hacked/

"But it wasn’t just Yahoo! email addresses that have been infiltrated: Gmail, MSN, Hotmail, Comcast and AOL accounts have also been hacked. (Yahoo! Voices allows you to sign in with non-Yahoo! email addresses.)"

[Mama Sumae]

I am such a cynic that my first thought was how helpful this news is for those advocating more internet policing.

[sleepyhead]

Does this also include Flickr?

[howdee]

This just goes to prove how aged yahoo platform really is and how lazy most of their programmers are. Or plain stupid? Not much of a difference, really. Any semi-decent web programmer (or indeed any other programmers that moved past "knowledge" gathered in those nice black & yellow booklets) will know better than to store user passwords directly in a database, and a poorly protected one at that, too. What a bunch of wallies! LOL! For those not in the know - only one-way "bcrypt" (or at the very least SHA256 or extremely well "salted" MD5) hashes of passwords should be stored since those can't be reversed back without insane amounts of processing power ("bcrypt" is considered "a slow algorithm" but still fast enough to verify user input), these hashes stored in a well protected database, hashes never exported for any purpose whatsoever and, of course, never used in any way to store user session data in cookies. Session IDs should also be completely random, long enough to make any brute force hacking near impossible, include a time-stamp on which they can be checked for validity (on top of their existence on the server, of course) and should expire within a reasonably small amount of time. I realize such approach means a minor inconvenience for users have they forgotten their passwords, but there's so many ways around it already in existence, I won't even bother explaining any. "Google" for it and remember you can do better than provide just a few possible password reminder questions than some other big companies do - enable users to also type in their own questions (DUH! Google! LOL). That's it folks, programming web for safe(r) surfing in a nutshell. Can't really trust some "yahoos" on that now, can we?

[cheesemp]

This just goes to prove how aged yahoo platform really is and how lazy most of their programmers are. Or plain stupid? Not much of a difference, really. Any semi-decent web programmer (or indeed any other programmers that moved past "knowledge" gathered in those nice black & yellow booklets) will know better than to store user passwords directly in a database, and a poorly protected one at that, too. What a bunch of wallies! LOL! For those not in the know - only one-way "bcrypt" (or at the very least SHA256 or extremely well "salted" MD5) hashes of passwords should be stored since those can't be reversed back without insane amounts of processing power ("bcrypt" is considered "a slow algorithm" but still fast enough to verify user input), these hashes stored in a well protected database, hashes never exported for any purpose whatsoever and, of course, never used in any way to store user session data in cookies. Session IDs should also be completely random, long enough to make any brute force hacking near impossible, include a time-stamp on which they can be checked for validity (on top of their existence on the server, of course) and should expire within a reasonably small amount of time. I realize such approach means a minor inconvenience for users have they forgotten their passwords, but there's so many ways around it already in existence, I won't even bother explaining any. "Google" for it and remember you can do better than provide just a few possible password reminder questions than some other big companies do - enable users to also type in their own questions (DUH! Google! LOL). That's it folks, programming web for safe(r) surfing in a nutshell. Can't really trust some "yahoos" on that now, can we?

Unless I misunderstood - this service was something that allowed Yahoo to log into a users email account held by another company. In which case using hashes wouldn't have worked (It'll only work locally with hashes as you know how to use the hashes). I am disappointed though that they didn't at least obfuscate/encrypt the passwords.

For local website accounts what you've said is correct though.

[watercooled]

To be pedantic, you don't have to use bcrypt; SHA256 (or SHA512 which is now Linux default for user passwords) is not inferior as you imply, and ALL passwords should be salted to protect against rainbow table attacks. MD5 is no longer considered suitable for cryptographic hashing. Any hash function should not be reversible, so bruteforcing (or rainbow tables without salt) is the only option; choosing a half decent password is important so bruteforcing is not plausible.

Even if they were storing credentials for other websites, storing them completely in the clear in a database is pathetic. A company as large as Yahoo should have set up a proper authentication process between themselves and the other party.