Slashdot Mirror


Nearly Half a Million Yahoo Passwords Leaked [Updated]

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

60 of 233 comments (clear)

  1. lastpass by Dave+Whiteside · · Score: 2

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

    --
    who where what when now?
    1. Re:lastpass by Anonymous Coward · · Score: 5, Insightful

      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.

    2. Re:lastpass by bedroll · · Score: 4, Informative

      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.

    3. Re:lastpass by Anonymous Coward · · Score: 3, Informative

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

    4. Re:lastpass by Runaway1956 · · Score: 4, Interesting

      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.

      --
      "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
    5. Re:lastpass by Anonymous Coward · · Score: 4, Funny

      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.

    6. Re:lastpass by bedroll · · Score: 4, Insightful

      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.

    7. Re:lastpass by Bengie · · Score: 4, Informative

      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

    8. Re:lastpass by Pieroxy · · Score: 2

      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.

    9. Re:lastpass by Bengie · · Score: 2

      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.

    10. Re:lastpass by mlts · · Score: 2

      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, the database would be stashed/synced in a format like OpenPGP where each key can open the database. That way, if the server storing it is compromised, the data is still encrypted until they get their hands on one of the people's devices and get access to that. Then figure out what the password is. Of course, there is always the issue of recovering access if all devices having keys to it are erased/lost/destroyed.

    11. Re:lastpass by nobaloney · · Score: 2

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

      Sure there is; they said it was a union attack. You get a thousand of those union goons coming after you with needles, and you succomb quickly.

  2. Ah, injection attacks.. by Rei · · Score: 5, Interesting

    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, ever.

    --
    sed "s/SJW.*$/... never mind. I was about to say something stupid, and also, I'm a troglodyte./Ig"
    1. Re:Ah, injection attacks.. by Simon+Brooke · · Score: 4, Interesting

      Here's probably the funniest discussion thread on injection attacks, ever.

      That is indeed funny, in a most terrifying way!

      --
      I'm old enough to remember when discussions on Slashdot were well informed.
    2. Re:Ah, injection attacks.. by ArcherB · · Score: 5, Funny

      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, ever.

      So, can I trust YOUR link?

      --
      There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
  3. File by Anonymous Coward · · Score: 5, Interesting

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

    1. Re:File by Anonymous Coward · · Score: 5, Informative

      http://it.slashdot.org/comments.pl?sid=2974701&cid=40627163

    2. Re:File by HyperQuantum · · Score: 5, Funny

      hunter2

      --
      I am not really here right now.
    3. Re:File by broggyr · · Score: 2

      Shit. Looks like I've been whooshed lol

      --
      Irony? Yea, it's like goldy and bronzy, only it's made of iron!
    4. Re:File by dsinc · · Score: 4, Informative

      https://d33ds.co/archive/yahoo-disclosure.txt The server is belly up, though, as I write this (7:15am PDT). Please mirror, if you can get your hands on the list. Another list of the compromised accounts (search enabled, no passwords), is here http://dazzlepod.com/yahoo/

    5. Re:File by N0Man74 · · Score: 2

      I'm paranoid, so I wondered the same thing about these "enter your address" lists on the 2 sites (that I had never heard of before) mentioned here.

      However, it works with partial search too. You don't have to have the entire address to match.

    6. Re:File by Thelasko · · Score: 4, Informative

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

      Here you go.

      --
      One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
  4. common security pratics ? by Rachael · · Score: 5, Interesting

    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.

    1. Re:common security pratics ? by Kyrene · · Score: 4, Interesting

      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.

      --
      Do not disturb. Already disturbed. http://www.teaaddictedgeek.com
    2. Re:common security pratics ? by Rei · · Score: 4, Insightful

      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.

      --
      sed "s/SJW.*$/... never mind. I was about to say something stupid, and also, I'm a troglodyte./Ig"
    3. Re:common security pratics ? by arth1 · · Score: 4, Insightful

      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.

  5. stinking unions by reasterling · · Score: 5, Funny

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

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

    --
    "For I desired mercy, and not sacrifice" -- God
  6. I've used yahoo voice in the past by circletimessquare · · Score: 2

    Just changed my password.

    Thanks Slashdot, seriously.

    --
    intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
    1. Re:I've used yahoo voice in the past by circletimessquare · · Score: 2

      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

      --
      intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
  7. That explains things by halcyon1234 · · Score: 4, Interesting

    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 =(

    1. Re:That explains things by deicide · · Score: 4, Informative

      And since I use plenty of folders, Gmail won't do here.

      Gmail works fine with folders. You can set up Thunderbird with Gmail's IMAP and then drag/drop your Yahoo folders onto it to migrate all your old mail.

  8. File here: by Anonymous Coward · · Score: 5, Informative

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

    1. Re:File here: by ledow · · Score: 3, Insightful

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

  9. Re:TWO moronic 'Americanisms' in one sentence! by Dog-Cow · · Score: 4, Insightful

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

  10. Re:Yahoo Mail? by ledow · · Score: 2

    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

    If nothing else, given their lax security and data protection (Completely unhashed passwords? Really?), I'd change any account password on a Yahoo account, and any password on an account you've used on Yahoo (e.g. if you've plugged your GMail or messenger or any address into your Yahoo acccount for whatever reason - e.g. POP3 collection of other accounts or whatever).

  11. something missing? by issicus · · Score: 2

    im sorry, maybe i missed something, how do i know if my password was stolen ? also YELLING isnt always a bad thing CAPS.

  12. Re:This company 'd33d' by ledow · · Score: 4, Insightful

    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.

  13. how about checking by Anonymous Coward · · Score: 2, Informative

    how about checking more than just this leak...

    have a look at http://bit.ly/rosGrL

    regards

    John Jones

  14. Plaintext passwords again? by gr8_phk · · Score: 5, Insightful

    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.

    1. Re:Plaintext passwords again? by Anonymous Coward · · Score: 5, Informative

      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.

    2. Re:Plaintext passwords again? by Anonymous Coward · · Score: 5, Funny

      What's wrong with users changing passwords every week?

    3. Re:Plaintext passwords again? by arth1 · · Score: 4, Insightful

      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.

    4. Re:Plaintext passwords again? by Svippy · · Score: 4, Informative

      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.

      --
      Clicked pie.
    5. Re:Plaintext passwords again? by Anonymous Coward · · Score: 2, Insightful

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

    6. Re:Plaintext passwords again? by somejeff · · Score: 5, Funny

      What's wrong with users changing passwords every week?

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

    7. Re:Plaintext passwords again? by Bengie · · Score: 2

      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 just buy a wrench and some thugs.

    8. Re:Plaintext passwords again? by TheLink · · Score: 2

      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 can pwned the site in so many other ways that it doesn't really make a big difference.

      My suggestion is to use a different password for each site that you care about.

      --
    9. Re:Plaintext passwords again? by charlieman · · Score: 2

      I think I'll start using variations of "FUCKYOUSTOPUSINGPLAINTEXTFORSAVINGPASSWORDS!!!" as my password. Too bad /. only allows 20 characters.

    10. Re:Plaintext passwords again? by ras · · Score: 2

      Should I even be taking that serious?

      Yes you should, because he is right. The major weakness of a hash is a collision attack. By chaining the hash's the way you have the potential for a collision attack is the sum of the parts. A better solution might be: salt||(h(salt||password) XOR f(salt||password)).

      then iterated hashes would get less secure the more iterations you use.

      Maybe they are. The enhanced security comes from it taking longer compute. Chaining may actually increase the chances of a collision, but at least chaining the same hash doesn't combine the weaknesses of two hashs.

      You have not given me even one reason to believe what you just claimed.

      Yes, he is being an arrogant prick. He comes off as more interested in demonstrating how l33t he is, not in discussing the issue at hand.

    11. Re:Plaintext passwords again? by ras · · Score: 2

      At least that statement is easily falsifiable. Even if a collision happened in the innermost hash, then that value is going to be concatenated with the salt and password before being hashed again.

      Sigh.

      If the inner hash collides, then it doesn't matter what the outer hash does. In the case of a collision the outer hash will always produce the same result, because operates on the same values. The salt and password are after all constants.

  15. Re:who uses yahoo by Zaiff+Urgulbunger · · Score: 3, Informative

    450000? so about 15 are real email accounts that people use.

    I only skimmed TFA and it seemed to indicate that these were probably related to the Yahoo! Voice service... whatever that is.

    As for their email, probably quite a lot of people do use it as some ISPs use Yayhoo! to supply their own-branded email. BT Internet in the UK for one anyway.

  16. Re:Am I missing something...? by JDG1980 · · Score: 4, Informative

    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" was created.

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

  17. Re:Obligatory by ElmoGonzo · · Score: 2

    About 15 years ago, I had a yahoo email address and managed to lose/forget the password. There was no recourse so I stopped using that account. Hmmm, I wonder if it is one of the ones that got leaked and I can find it now.

  18. Re:Am I missing something...? by drkstr1 · · Score: 2

    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.

    --
    Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
  19. Re:Am I missing something...? by fatphil · · Score: 2

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

    --
    Also FatPhil on SoylentNews, id 863
  20. Re:Am I missing something...? by Fwipp · · Score: 2

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

  21. I imported them into Excel... by Gordo_1 · · Score: 3, Interesting

    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

  22. Thanks god for mysql_escape_string and mod_sec by detain · · Score: 2

    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.

    --
    http://interserver.net/
  23. Yep, Yahoo Mail, this goes further than reported by almechist · · Score: 3, Informative

    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 repeat, I have had a totally spam-free yahoo mail address for 5 years and all of a sudden today I get spam, despite the fact that my address is NOT listed in the list of compromised accounts. Make of this what you will, but personally I'm not very happy with Yahoo at the moment.