Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security Privacy Yahoo! IT

Nearly Half a Million Yahoo Passwords Leaked [Updated] 233

An anonymous reader writes "Some 450,000 email addresses and associated unencrypted passwords have been dumped online by the hacking collective 'D33Ds Company' following the compromise of a Yahoo subdomain. The attackers said that they managed to access the subdomain by leveraging a union-based SQL injection attack, which made the site return more information that it should have. According to Ars Technica, the dump also includes over 2,700 database table or column names and 298 MySQL variables retrieved during the attack." Update: 07/12 20:03 GMT by T :Reader techfun89 adds this update: "Yahoo has confirmed that the usernames and passwords of more than 400,000 accounts were stolen from their servers earlier this week and that data was briefly posted online. The information has since been removed but it wasn't just credentials for Yahoo, but also Gmail, AOL, Comcast, Hotmail, MSN, SBC Global, BellSouth, Verizon and Live.com as well."
This discussion has been archived. No new comments can be posted.

Nearly Half a Million Yahoo Passwords Leaked [Updated]

Comments Filter:
  • Re:lastpass (Score:5, Insightful)

    by Anonymous Coward on Thursday July 12, 2012 @08:53AM (#40627027)
    I sure wish these dumbasses would learn to secure their shit. SQL injection AGAIN? There's just no damned excuse for it.

    This isn't hard to test for. Hell this isn't hard to guard against. This is a "oh I'll just shoot myself in the foot now, ah-hyuk! *BANG* Ow that hurts what happened?" type of negligence.

    If the incompetent designers don't get their shit together you're going to see gov't get involved. All it would take is for a hack to finally affect the "right" people. Nobody wants that except gov't.
  • by Rei ( 128717 ) on Thursday July 12, 2012 @08:59AM (#40627079) Homepage

    I think in most cases, they honestly don't know any better, followed by as the next most likely reason, they were too lazy. Sinister reasons is probably number three. I doubt optimization makes the top 10.

  • by shentino ( 1139071 ) <shentino@gmail.com> on Thursday July 12, 2012 @09:04AM (#40627137)

    The only answer is that if the guy who owns the fucking playground doesn't want you on their toys, leave.

  • by Dog-Cow ( 21281 ) on Thursday July 12, 2012 @09:15AM (#40627215)

    You are not an idiot. Idiots are brilliant in comparison to what you are.

  • by ledow ( 319597 ) on Thursday July 12, 2012 @09:25AM (#40627291) Homepage

    1) To show they can
    2) To make Yahoo look bad (and boy should they look ashamed at the moment!)
    3) To highlight a security flaw that Yahoo may have been knowingly ignoring
    4) Because they stumbled across it and realised they COULD dump all the passwords and then it snowballed.

    Or a million and one other reasons. Hell, I've found sites where I could have done all sorts of damage via SQL. Not everyone is nice enough to inform them and if you inform them and are ignored ("nobody would ever try to do that on our live website, so we won't fix it"), would you rather someone else found out, or you forced that site to tighten up?

    Just think - if they hadn't done it, 450,000 people would have their emails and passwords floating around on hacker forums eventually anyway and it wouldn't make the news at all.

  • Re:File here: (Score:4, Insightful)

    by ledow ( 319597 ) on Thursday July 12, 2012 @09:30AM (#40627345) Homepage

    Because not having your password appear on a single leaked list of a limited number of usernames hacked from Yahoo by an SQL injection from a public site from an unhashed database is obviously reason to just relax and know that everything is okay.

    Who cares if you're on the list? If you're using Yahoo, change your password, change your account, change your online service provider to anything but Yahoo.

    SQL injection on public sites with unhashed passwords stored in open databases. This is like saying "Hell, my house wasn't burgled this week - Phew! I can continue using the security company whose alarms don't work, their security personnel never arrive and they leave all my doors unlocked!"

  • by gr8_phk ( 621180 ) on Thursday July 12, 2012 @09:34AM (#40627381)

    SQL injection AGAIN? There's just no damned excuse for it.

    Several people have made similar comments. What worries me is that they are not also slamming them for storing passwords in plaintext AGAIN. User passwords should not be stored anywhere on the system. You store a salt and hash of the password - this is fine for login, but fairly useless for hackers should they get it.

  • by arth1 ( 260657 ) on Thursday July 12, 2012 @10:04AM (#40627607) Homepage Journal

    What's wrong with users changing passwords every week?

    I'll tell you what's wrong with that: Most users are human, and won't be able to remember their passwords if they change them often. Especially since most people have a handful or more passwords and PINs they have to remember.

    Frequent password changes lead to either simplified passwords with a single short element that changes, or passwords that are written down on a post-it note or similar.

    The greatest enemy of safe authentication is the CFO. After him or her, it's the user. You have to get both to play ball, and you don't do that by annoying either of them.

  • by Anonymous Coward on Thursday July 12, 2012 @10:13AM (#40627665)

    Expensive hashes help regardless. You're always in a race against computing power. Take whatever handicaps you can get.

  • by arth1 ( 260657 ) on Thursday July 12, 2012 @10:17AM (#40627715) Homepage Journal

    I think in most cases, they honestly don't know any better, followed by as the next most likely reason, they were too lazy.

    Never underestimate the push of S&M to get things out the door, not as soon as possible, but earlier than that. Waiting days or weeks for proper authentication to be implemented and tested means days or weeks without sales bonuses for them. They'll likely be long gone by the time anyone breaks in anyhow.

    It doesn't matter much if the developers and technical admins say that it's sheer lunacy if the CFO says you need to release nao because S&M told him so.

    It's even worse in companies that work on a project model where they move all devs and techs who know the project off it at release, without ever looking back. Then it's a certainty that it'll never get fixed.

  • Re:lastpass (Score:5, Insightful)

    by bedroll ( 806612 ) on Thursday July 12, 2012 @11:30AM (#40628391) Journal

    The problem with local storage is that you're responsible for securing your local device. That makes you much more susceptible to a direct, targeted attack. It also makes you beholden to the security of the various systems you use.

    Correct usage of Keepass will likely give you a more secure password database than Lastpass's vault. The non-standardization and decentralization of that method will make you less susceptible to mass database leaks. Even if you use Dropbox (which has some serious security concerns itself) and that service were compromised the attacker would have a hard time getting all of Keepass vaults out. So, that argument holds.

    Where it fails is if you are targeted, and even worse if you are not an advanced user. In a hand-spun system like this you are the one who has to monitor for intrusions, and you are the one who has to design the security and maintain it. If you store your password database in Dropbox I believe the exploit of stealing a machine authentication token will still allow an attacker to gain access to your files, which may allow them to begin cracking your password without your knowledge. Once they've gotten a copy of your encrypted file it does not matter if you change your password because it won't change their copy. This becomes a real problem if you're not an advanced user whose setup strong encryption on your database or if you've used a weak password, let alone the issues with a standard user using and maintaining such a system.

    Targeted attacks are scary. One can assume that if a victim is targeted it is because the attacker knows there is value in the additional work. If we assume that the effort to decrypt a Lastpass vault is not significantly less than any other strongly encrypted container then we can infer that a compromise of Lastpass (or 1Password, or other such services) would be comparably expensive because each vault has an unknown value. Long story short, I'm far more concerned with a targeted attack than I am a database leak in this case. I'd rather have a service focused on security monitoring for intrusions, even if that doesn't excuse me from maintaining a reasonable level of security on my own devices.

I've noticed several design suggestions in your code.

Working...