Forgot your password?
typodupeerror
Security Privacy Yahoo! IT

Nearly Half a Million Yahoo Passwords Leaked [Updated] 233

Posted by timothy
from the drop-in-the-bucket dept.
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:
  • by Dave Whiteside (2055370) on Thursday July 12, 2012 @08:49AM (#40626991)

    you know it makes sense ...
    every day there is another hack .... just waiting for the lastpass one now....

    • 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 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 Anonymous Coward on Thursday July 12, 2012 @09:39AM (#40627423)

          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.

          You don't store just any hash, you should store one that is expensive to compute, by using PBKDF2, bcrypt, scrypt or similar.

          • by Bengie (1121981)
            Expensive hashes are only good for weak passwords. Users shouldn't have week passwords. Just use a strong salted-hash, that's Good Enough(tm), don't care about slowness.
            • by Anonymous Coward on Thursday July 12, 2012 @09:53AM (#40627527)

              What's wrong with users changing passwords every week?

              • 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 Svippy (876087) on Thursday July 12, 2012 @10:12AM (#40627663) Homepage

                  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.

                  Correct, but I think he was pointing out that Bengie wrote 'week passwords' rather than 'weak passwords', i.e. I think the post was meant to be humorous.

              • by gmuslera (3436)

                Will be for most users changing passwords 7 times a week. One for changing it, the other 6 for the "i forgot my password" link. Is a problem, not a solution. One password for each service is bad enough, forcing to change it to something different every week would be killer.

                Anyway, that most are 123456 or password, and that the server stored it in plain text or in a format where is easy to obtain the original one puts the problem several layer over the forcing changing it or not one.

                • back during the dot com boom, the boss registered the name poiuyt.com. The emails began to pile up quickly, mostly password confirmations for people who didn't want to give up the real emails, it was quite amazing how many user poiuyt had qwerty as their passwords, second was qwerty as the user with poiuyt as the password.

              • by somejeff (825047) on Thursday July 12, 2012 @10:45AM (#40627953) Journal

                What's wrong with users changing passwords every week?

                I agree. I do it. This week it's Yahoo$20120708

            • Re: (Score:2, Insightful)

              by Anonymous Coward

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

              • by Dishevel (1105119)

                Just because my password can take 15.7 trillion years to crack dose not mean the it will take that long.

              • by Bengie (1121981)

                You're always in a race against computing power.

                Even if a hash was O(1) and took one clock-cycle no matter the password length, a 14+ char password will be safe for a very very long time. If you had EVERY computer in the world working on colliding your hash, to find your password, it would take decades even if they're lucky and found a way to make 500ghz graphite chips.

                In the real world, hashing scales with the stream length and takes several cycles per char, plus look-up times and no 500ghz chips.

                If someone wanted your password so badly, they would

            • by TheLink (130905)
              But why should I waste my time typing strong passwords for sites I don't care that much about?

              Especially if they're going to get pwned and my password ends up visible to the whole world? Because too often the idiots store the passwords in a reversible format. From what I see some of those yahoo passwords released aren't that trivial e.g. %5M%us$@7U
              What are the odds the attackers brute-forced that and the other harder passwords?

              If they can dump the hashed passwords for brute forcing, it usually means they ca
        • From the article:

          It is still unknown whether the passwords were retrieved in the clear text format or were decrypted by the attackers afterwards.

          Its possible they were stored hashed, and simply cracked. That, however, WOULD strongly imply either no salt or a single global salt.

      • Re:lastpass (Score:5, Interesting)

        by Runaway1956 (1322357) on Thursday July 12, 2012 @09:42AM (#40627447) Homepage Journal

        You're probably right. What's scary is - the government isn't a whole lot better at this stuff. I seem to recall a recent transatlantic telephone conference, involving multiple "intelligence" and/or "enforcement" agencies that was recorded by the very people being discussed.

        Yeah, I really want some alphabet soup dude from Washington looking out for my internet security.

        • by dkleinsc (563838)

          Yeah, I really want some alphabet soup dude from Washington looking out for my internet security.

          I might want that, because the government guy at the very least doesn't have a short-term financial incentive to skimp on doing a decent job of it.

          Imagine, if you will, a company where the tech team has done a fantastic job of buttoning everything up tight, and has some smart guys who focus on really keeping things secure. New manager comes in: "Hey, we could cut back a bit on the size of our security team, our customers won't notice a difference, and we'll save $500K a year!" His boss will almost definitel

      • by mr1911 (1942298)

        If the incompetent designers don't get their shit together you're going to see gov't get involved.

        That will certainly fix it. I can't wait for a bunch of lawmakers that think SQL is some sort of 'dirty text talk the kids use' to secure us online. No one can be sure what they will come up with, but the odds are pretty strong it would include a full body scan (with the ability to opt-out and get groped by the TSA instead) to get on the internet.

      • Re:lastpass (Score:4, Funny)

        by Anonymous Coward on Thursday July 12, 2012 @10:08AM (#40627633)
        Please, don't be so harsh on SQL Injection victims. It happens all the time, and even to the best developers. Even at Yahoo! Look, between you and me, we at Sony suffered a lot from attacks - allegedly SQLi attacks... but actually, it was something else: you say "guard" against it? We have here the best Javascript developers. Our JS code checks the user input several times, even before it reaches our servers! No, you really don't know what you are talking about.
        • Re:lastpass (Score:5, Informative)

          by Bengie (1121981) on Thursday July 12, 2012 @12:19PM (#40628951)
          SQL injection is insanely easy to protect against. Your input should NOT be in your command stream

          C# pseudo-syntax
          sql.CommandType=Procedure
          sql.command = "MyStoredProcedure"
          sql.parameters.add("@MyInput",InputValue)


          You will never get an SQL injection through that.(assuming MyInput isn't a string that gets concatenated to dynamic SQL inside the sproc)

          You could even do something like this

          sql.CommandType=Text
          sql.command = "select * from table"
          if(InputValue != null) {
          sql.command += " where table.myfield = @MyInput"
          sql.parameters.add("@MyInput",InputValue) }

          This is also safe from injection
          • by Pieroxy (222434)

            Usually, everyone knows that. The problem is on the trainee you hired for almost nothing, and as (s)he costs almost nothing, you don't want to invest time in them, so they are alone in their cubicle. They commit things and nobody looks it over.

            Of course, they're trainees, n00bs that don't know better than to concatenate strings to build sql queries.

            All in all, in a fair amount of these cases, I'm sure it's bad management instead of poor technicians/developers.

            • by Bengie (1121981)
              I agree. Bad management encouraging/enabling poor technicians/developers by not looking for quality hires.

              Either way, we can still blame Yahoo as they have a professional responsibility to make sure their employees know common industry standards. Protecting against SQL Inject is common knowledge. I learned about it sophomore year and StackOverflow users mention it in almost every case where it could happen when a question is posted.
      • There's certainly no excuse for a company like Yahoo, that's for sure.

    • Re:lastpass (Score:5, Informative)

      by bedroll (806612) on Thursday July 12, 2012 @09:08AM (#40627165) Journal

      This wouldn't terribly shock me, but it also wouldn't concern me much if it were to happen. While the data in a Lastpass vault is quite desirable, it's also much more securely stored than your average data set. Even if someone managed to get a dump of their entire data set they'd have to decrypt each vault individually. If you follow their recommendations then your vault is likely not easy to crack.

      Most of all, I wouldn't be concerned because as Lastpass has shown in the past they take communications seriously. When they noticed strange traffic they immediately told their users to change their vault passwords. This is different than waiting for a whistle blower to come forward and then announcing the breach, or even waiting until an investigation proves there was no breach. That previous incident may have shook the faith of some, but the way the company handled it increased my faith in them.

      Should a major breach happen I would simply change my vault password and then begin changing the passwords I have stored in the vault. Since Lastpass would alert me early on that the breach happened, by the time my vault was cracked - if at all - the passwords within would be useless.

      • by mlts (1038732) *

        What might be ideal would be a way for an front end to Lastpass to be able to communicate a keyfile to other devices. So, one can have a local keyfile stashed on their workstation, a keyfile on their mobile device, and one on their tablet.

        This in combination with a password would make unauthorized access to a Lastpass database pointless. Unless the attacker is able to get at people's devices, they won't be able to get the keyfile, and without that, brute forcing the password is pointless.

        I do this with TC

        • 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.

          • by mlts (1038732) *

            Nail, head hit.

            To boot, with all the information floating around, it is easy to do a targeted attack. I'm sure GPS info can be obtained to track where someone goes in a day. Combine that with some criminal element in a local area doing the HUMINT (or just basic thuggery), and things can get pretty scary.

            What I would like to see is a service similar to LastPass except that every device, be it a computer, smartphone, tablet, or embedded PDA dedicated for authentication would have a public/private key. Then

    • Re: (Score:3, Informative)

      by Anonymous Coward

      Better to use keepass then, because there is no central database of passwords for that.

  • by Rei (128717) on Thursday July 12, 2012 @08:52AM (#40627017) Homepage

    when will people ever learn? And not just SQL injection attacks. I had to actually write a destructive exploit for a popen injection attack on a MMORPG before the rest of the dev team would believe me that it was a serious vulnerability (it had code that if you said a URL, people could click on it... except they were just passing what the user wrote to popen, tacked to the end of your browser-launch string). People just never seem to wrap your head around the fact that you never use raw user input for anything that a parser will look at, at any point in time!

    Here's probably the funniest discussion thread on injection attacks [thedailywtf.com], ever.

  • File (Score:5, Interesting)

    by Anonymous Coward on Thursday July 12, 2012 @08:52AM (#40627019)

    Does anyone have a link to the leak? You know, I want to check if my password was leaked.

  • by Rachael (244242) on Thursday July 12, 2012 @08:55AM (#40627049)

    Seems to be common pratics that sites store plaintext password this days, one would think the programmers knew better, is it in an attempt to try and speed optimize things, they leave out hashing ?
    Or is there a more sinister reason, someone twisting their arm around.

    • by Kyrene (624175) * on Thursday July 12, 2012 @08:57AM (#40627069)
      Once worked in a place where the "architect" swore up and down that his "philosophy" was that if people were to hack into the database, they wouldn't then get the keys to the account, they'd go for other details like credit cards and what-not, so there was no reason for encryption. Very glad I'm not working there anymore because arguing with him was useless. Once his mind was made up, that was that.
      • Re: (Score:2, Insightful)

        by shentino (1139071)

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

    • 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 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.

    • But this time it was okay.. It was probably on a development system, and everyone knows nobody can get to the server, its behind "The Firewall".

    • Seems to be common pratics that sites store plaintext password this days, one would think the programmers knew better, is it in an attempt to try and speed optimize things, they leave out hashing ?
      Or is there a more sinister reason, someone twisting their arm around.

      Any sytem that can't handle the overhead of a hash function is already on the edge of the abyss to begin with.

      As for "sinister reasons", try "We get our programmers for Lower Prices Everyday[TM]".

  • by reasterling (1942300) on Thursday July 12, 2012 @08:58AM (#40627075) Homepage

    they managed to access the subdomain by leveraging a union-based SQL injection attack.

    So, the republicans are right. Unions are evil. ;)

  • Just changed my password.

    Thanks Slashdot, seriously.

    • by sticks_us (150624)

      Just dumped all my yahoo accounts (had two spam accounts and one personal account).

      I've had them since the late 1990s, and while I hate to kick someone while they're down, the service has only gotten worse lately--spam, unwanted yahoo! instant messenger robot requests, "Temporary Problems Accessing Your Account" messages--the whole deal.

      This kills it for me. I interviewed with Yahoo! about six years ago (didn't make it past the second cut, so yeah, I'm a moron) and being VERY impressed with how smart their

      • did you use yahoo voice? only yahoo voice customers were affected

        not that this story shouldn't change your opinion of yahoo, and therefore dumping them is a good choice on your part

        i'm just saying the article specifically mentions yahoo voice customers as the victims, which i was about 2 years ago, but, if you weren't, you should be ok

      • by fatphil (181876)
        "Wonder if all the good ones left or got fired somewhere."

        I do remember reading of several firing sprees in the last few years. The best are often the first to leave even when the firing spree is only intended to clear out deadwood.
  • That explains things (Score:5, Interesting)

    by halcyon1234 (834388) <halcyon1234@hotmail.com> on Thursday July 12, 2012 @09:00AM (#40627089) Journal
    That explains why, about a month ago, I got a whole rash of "omg funy click here" spam mails for friends with yahoo email addresses (and only yahoo email addresses). I wonder how recent this password dump is. I might have to recommend another round of reset-to-something-complex. My first recommendation was STOP USING YAHOO FFS!, but no one does that =(
    • by unixisc (2429386)

      Thanks for saying what it was. A month ago, I saw a whole bunch of message unsuccessful to everyone in my contact, which actually is a huge number since I have all job contacts there. Two or three people told me that I was infected w/ a virus. I used Thunderbird at the time as my e-mail client, but following this, I changed my password. I recognize that I may have to migrate this account, but it has too much of stuff to make it a trivial exercise. And since I use plenty of folders, Gmail won't do here.

  • File here: (Score:5, Informative)

    by Anonymous Coward on Thursday July 12, 2012 @09:08AM (#40627163)

    http://d33ds.co/archive/yahoo-disclosure.txt

    Slashdotted, more info here:
    http://dazzlepod.com/yahoo/

    SQL Injection, in this day and age?

    Fuck yahoo, fuck the cloud, fuck all the big providers...

    • by jonwil (467024)

      Thanks for that link, looks like my password was not stolen.

      • 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!"

  • Does this include Yahoo Mail accounts?

    I know that, awhile back, my account was logged into from some other country (someplace in South East Asia, IIRC) and a bunch of spam links were sent to my contacts. I had a complex password and they didn't change any information. (Odd, since I thought one of the first things a hacker would do is change the password to hold onto the hacked account.) I changed my password and sent folks notice about the hacking. (No, I didn't click on any links or run any programs th

    • by ledow (319597)

      I don't know, it seems to be quite limited. There's tons of gmail and other domain addresses in there. I think it could be either what you signed up to Yahoo Voice as, or what you signed up to Yahoo as and they only got some addresses before they got caught (or aren't posting all the adddreses they captured).

      There's even a few old Geocities addresses in there, which were later changed to "username.geo@yahoo.XXX" addresses when Yahoo took over:

      http://dazzlepod.com/yahoo/?email=.geo%40yahoo [dazzlepod.com]

      If nothing else,

    • I have an att.net email account which for some reason has to be accessed through Yahoo, I guess they're corporate partners or something... The point is, I have always protected my email address with religious fervor, and as a result I do not get spam, ever, period, not once. Until today, that is. Make of it what you will, but to me this is just way too much of a coincidence. I strongly suspect it will come out that the hack went deeper and compromised much more than what is currently being reported. To repe
  • Having my password leaked online with all the potential that that holds is far less abusive than what Yahoo! does with the information in my emails.
  • im sorry, maybe i missed something, how do i know if my password was stolen ? also YELLING isnt always a bad thing CAPS.
  • Obligatory xkcd reference

    http://xkcd.com/327/ [xkcd.com]

  • I presume that you cannot actually reach the DB directly (it is shocking how many people in smaller companies have their DB actually in their DMZ), so they must be pushing the SQL injection through an actual Yahoo API, right?

    How hard is it to evaluate a string for potential danger?

    Surely API calls can be divided into context and 'grammars' of a sort, then these API calls can identify whether a given string is more or less likely to be a threat by keywording, if anything is suspicious (and at this level ther

    • How hard is it to evaluate a string for potential danger?

      If you are evaluating a string for danger, you're doing it wrong.

      I'm starting to think that web developers should be licensed before they're allowed to generate a single statement of SQL.

      • by Assmasher (456699)

        I'm not sure I understand where you're going with this, I evaluate ALL external input (not just from users) for danger.

        I'm not a web developer though (mobile/thick client/enterprise only) which is why I asked if I was missing something since this seems trivial to do...

        • by drkstr1 (2072368)
          Not all dangers can be known, so it is better to parse for what you need (white list), and use it as data in a type safe command (ORM, stored procedure, etc). This insures that only operations that will run are the ones you have written yourself.
    • by JDG1980 (2438906) on Thursday July 12, 2012 @09:45AM (#40627469)

      How hard is it to evaluate a string for potential danger?

      Pretty hard, if you don't want to corrupt user data. A botched attempt to do so is how the bogus word "medireview [wikipedia.org]" was created.

      What they really should be doing is using parameterized queries [codinghorror.com] so that the user-input strings cannot be treated as SQL commands, but will always be treated as data.

      • by Assmasher (456699)

        I didn't say "correct potential danger", I said "evaluate." Replacing things is (a la medireview) is a flat out stupid approach anyhow, lol (thanks for the link - it made me laugh.)

        I agree that everyone should use parameters instead of string concatenation, but that doesn't make things safe, it just makes them a little bit safer. Parameters don't help if someone passes the user name "';drop table important_table"

        ALL input MUST be sanitized whether you use parameterized SQL or not; ergo, you must evaluate

        • by Fwipp (1473271)

          Actually, parametrized queries do completely eliminate the 'pass the user name "';drop table important_table"' vector.

    • by fatphil (181876)
      > How hard is it to evaluate a string for potential danger?

      Utterly trivial.

      If it came from an external source, it's a potential danger.

      Never ever put anything that is potentially dangerous anywhere where it could do anything dangerous. E.g. do not build queries out of it. This may have many false positives, but it has no false negatives. And if you're going to fail, fail safe, don't fail unsafe.
  • Lots of sites are reporting this, and apparently enough ppl still have yahoo accounts that they care enough to change the password on, I wasn't able to login.
  • I did some quick looking around but, can't find a link to the actual list of accounts and passwords. Anyone found it?

    Seems to me that just a few months ago, before pastebin got their panties in a bunch about password lists, it was a lot easier to check and see if your accounts are on the list.

    Not even sure if mine are, or if any are that I care about, most of them, I think, have good passwords but fuck, it would be nice to know. Hell, there is no garauntee that even a good password doesn't hash to the same

    • by synapse7 (1075571)
      The list is linked in posts above. Since yahoo sites share a common login, yahoo mail accounts would also be compromised if the user used a yahoo address to register. Users that registered iwth an address from another domain that also use the same password everywhere may also be in trouble.
  • Usually, when you see one of these happen, you can find a list somewhere, so you can see if you're on it. I can't seem to find the actual list this time. Does one exist?
  • Fuck! How many fucking fucks are there?! I didn't count them all but I got some 15 passwords including the four letters "fuck" per ten thousand passwords.

  • I'm far from an expert in this area but don't certain ORM frameworks like Hibernate automatically prevent attacks through SQL injection? Though if they're storing plain-txt passwords, I doubt they're using any such frameworks.
  • I had a strong password "sXbi51VN" and I don't use yahoo voice and I checked out ok with the compromise database but my password was still changed! Got the account back thankfully.

  • Maybe I don't know enough about user account management, so if I am misinformed, somebody please fill me in.

    Is there a reason that so many of these big-name corporations are not employing hashes? I mean, the SHA algorithms (for example) aren't exactly hard to come by so it's not like they have to reinvent the wheel. Every DBMS worth its salt has these functions built into it. Is SHA1($password) too much for them to type?

    I just cannot fathom why they would ever store unobfuscated passwords...

  • by Gordo_1 (256312) on Thursday July 12, 2012 @12:04PM (#40628785)

    For your viewing pleasure, here are the top 20 passwords by number of occurrences in the Yahoo hacked set. Enjoy!

    Password Count
    123456 1673
    password 804
    welcome 439
    ninja 333
    abc123 255
    123456789 226
    princess 216
    sunshine 213
    12345678 208
    qwerty 177
    michael 167
    writer 166
    monkey 165
    freedom 164
    password1 162
    111111 160
    iloveyou 142
    tigger 136
    baseball 136
    shadow 134

  • Thanks god for mysql_escape_string and mod_security. Certain large companies like Yahoo you just assume they have the money and time to make sure all of there code is tight, this is pretty lame on their part.

"It's curtains for you, Mighty Mouse! This gun is so futuristic that even *I* don't know how it works!" -- from Ralph Bakshi's Mighty Mouse

Working...