Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Privacy Security Mozilla Your Rights Online

Mozilla Posts File Containing Registered User Data 154

wiredmikey writes "Mozilla yesterday sent an email to registered users of its addons.mozilla.org site, letting them know that it had mistakenly posted a file to a publicly available Web server which contained data from its user database including email addresses, first and last names, and an md5 hash representation of user passwords."
This discussion has been archived. No new comments can be posted.

Mozilla Posts File Containing Registered User Data

Comments Filter:
  • by Anonymous Coward

    at least they told their users

  • TFA says that it was the user database of the AMO (addons.mozilla.com) website, nothing to so with the Sync server.
  • by Giorgio Maone ( 913745 ) on Tuesday December 28, 2010 @05:24AM (#34684514) Homepage
    http://blog.mozilla.com/security/2010/12/27/addons-mozilla-org-disclosure/ [mozilla.com]
    Active accounts have their password SHA-512 hashed with per-user salt, so they're safe (for a while). However those 44,000 holders of older (and now disabled) MD5 hashed accounts should rush changing their passwords elsewhere, if they have the bad habit of using the same password everywhere...
    • However those 44,000 holders of older (and now disabled) MD5 hashed accounts should rush changing their passwords elsewhere, if they have the bad habit of using the same password everywhere...

      If they can remember what password they used and where else they might have used it... I got the email, but i'm buggered if i know what password i used for that account. Chances are it was a disposable one that i use for accounts i don't care about, but i couldn't say for sure.

      • If they can remember what password they used and where else they might have used it...

        If you use Firefox's password manager you can ask it (Tools|Options|Security|Saved Passwords|Show passwords) and even search among its entries, by site, username or password.

        Otherwise I'm afraid you will need to change them all :(

      • Re: (Score:2, Funny)

        by Yvanhoe ( 564877 )
        I always wondered what the implications of password reuse were...
        http://xkcd.com/792/ [xkcd.com]
        Ok, maybe not that bad
      • by tukang ( 1209392 )
        why don't you md5 some of your guesses to see if the hash matches? this assumes they didn't salt the md5 hashes
    • by Rich0 ( 548339 ) on Tuesday December 28, 2010 @08:45AM (#34685450) Homepage

      if they have the bad habit of using the same password everywhere

      What alternative do you propose? I must have accounts on 100 different websites by now, including this one. I can't create and remember 100 distinct strong username/password combinations on all of those websites. Unless you're an autistic savant you can't either.

      Passwords are false security - they are a way to CYA and blame the victim for causing the problem, while giving them no realistic solution. Sites that depend on their users choosing unique passwords for security are simply insecure, period.

      • > I can't create and remember 100 distinct strong username/password combinations on all of those websites

        Apparently "computers" can be "programmed" to perform information retrieval operations.

        Perhaps some "software" such as PasswordSafe or MyPasswordsafe could be used for password creation, secure storage and on-demand retrieval.

        • by Rich0 ( 548339 )

          That's great, and how do you propose keeping all those passwords secure and synchronized across multiple devices and operating systems, some of which I'm not permitted to install software on?

          It isn't like I only access the web from one terminal...

          • That's great, and how do you propose keeping all those passwords secure and synchronized across multiple devices and operating systems, some of which I'm not permitted to install software on?

            postit notes of course!

            Ok, I use Keepass which is brilliant, and will work on your phone too, so you have no excuse to have a DB of passwords (randomly generated by Keepass itself if necessary). The db and app is tiny and will happily install onto other systems (by copying the keepass binary and the db file) so you only

          • by brusk ( 135896 )
            Lastpass.
            • by Rich0 ( 548339 )

              Looked into it - doesn't seem like it supports android unless you pay for it. Keepass seems to be another popular option, but that doesn't support Chrome OS.

              It seems like these are all bandaids - SSL or something like that is probably a better option, with the key being kept in a smartcard. We just need to have the browser standards updated so that future browsers refuse non-SSL connections in the future so that everybody gets on-board. I don't see that happening anytime soon, but that is what it would p

              • by tepples ( 727027 )

                We just need to have the browser standards updated so that future browsers refuse non-SSL connections in the future so that everybody gets on-board.

                Such a future is far off. Obligate use of HTTPS won't happen until either A. all cable, DSL, satellite, and mobile ISPs offer IPv6 service, or B. people stop using Windows XP and other non-SNI-supporting SSL stacks. All the free StartCom SSL certificates in the world won't help if you don't have a dedicated IP address to know which certificate to send to the client who has connected to your web server:443 and wants to see a cert before providing the HTTP/1.1 Host: header.

                • by Rich0 ( 548339 )

                  Why does strong authentication require every client to have a static IP/etc?

                  I can implement a webapp today that uses client-side SSL certificates for authentication just fine, without the client having a static IP/etc. The only thing that is missing is getting the private key off of the PC and onto a smart card/etc.

                  There is no reason that such a standard needs to be implemented in a poor way.

                  • Why does strong authentication require every client to have a static IP/etc?

                    Current SSL requires the server to have a dedicated IP per hostname, not name-based virtual hosting, because it has to send the certificate before it gets a chance to see the Host: header. It need not for the client because the client already knows what client-side certificate to send for a given host.

                    The only thing that is missing is getting the private key off of the PC and onto a smart card/etc.

                    Agreed. I just wanted another chance to remind readers of why HTTP without SSL still exists at all. Another problem is how to get the web site to distinguish between an authentic smart card and a PC that has b

                    • by Rich0 ( 548339 )

                      The way you tell if the smart card is authentic is via challenge-response. When you create a gmail account you send the server a certificate from your smartcard. When you log in you provide the certificate again, the service sends you a challenge which you give to the smartcard, and the smartcard prompts for a PIN on its internal keyboard, and then after verifying the PIN it computes a response using the private key stored inside that never leaves the card.

                      Without extracting the key from the physical smar

              • We just need to have the browser standards updated so that future browsers refuse non-SSL connections in the future so that everybody gets on-board.

                Why exactly do I need HTTPS to connect to any random website where I don't log on to? Why would I need to lose proxy level caching, add overhead (both in CPU and traffic), forcing small websites to pay for certificates, etc?

          • Depending on your usage/network availability I would recommend either LastPass or a combination of KeePass and a file-syncing solution like dropbox.

            If anywhere you would need your passwords you have internet access, LastPass is completely web-based and has good phone integration with mobile versions of the site and apps.

            If you may need to access your passwords with no internet access available or do not trust a third-party with your passwords, I would recommend KeePass and a file-syncing solution. It uses a

          • SuperGenPass [supergenpass.com] is a simple bookmarklet that can generate hashed passwords based on a master password. Like KeePass and LastPass you only need to remember one password, but unlike those, it doesn't store anything and you can use it pretty much anywhere.

      • by MobyDisk ( 75490 )

        I can't create and remember 100 distinct strong username/password combinations on all of those websites

        You don't have to if you use a hash. Ex: My slashdot password = my base password + an easily computable hash of the word "slashdot." You know ASCII? Take the ASCII values for the first and last vowels of the site and sum them together. Something like that. Do the same for every site, then write down the user name + the word you used to hash it. (It is usually easy to guess, but with some sites you have to make rules like remove the spaces and punctuation or ignore the numbers)

        • by Rich0 ( 548339 ) on Tuesday December 28, 2010 @10:10AM (#34686280) Homepage

          I think you're stretching "easily computable" - when I want to log into a website I don't want to spend 10 minutes with a calculator and an ascii table, or require access to the md5sum application.

          Plus, this only works if it remains an uncommon way of generating passwords. If it becomes commonplace, then if a hacker can run through a bazillion md5 sums do you think that it will take them long to include variants of site names represented as ascii in their attacks? Once they figure out your algorithm through brute-force then it can be trivially applied to any other sites you have accounts on.

          • by MobyDisk ( 75490 )

            I think you're stretching "easily computable" - when I want to log into a website I don't want to spend 10 minutes with a calculator and an ascii table, or require access to the md5sum application.

            Then do whatever you are comfortable with in your head. I just gave an example.

            Once they figure out your algorithm through brute-force then it can be trivially applied to any other sites you have accounts on.

            Yes, that is a valid limitation. But it is not a reason to avoid using the algorithm. Most hackers aren't interested in determining your personal password trick, that takes too much time. They want to grab that Bugzilla password and try it on your bank accounts. When it doesn't work, they will move on to the next person.

            The point is, this trick is not perfect security. But it is an enormous improvement over using the same p

      • by MosX ( 773406 )

        Why don't you just incorporate the first couple of letters of the site used into the password?

        • by Rich0 ( 548339 )

          What would be the point?

          Suppose the gizmodo password hashes are leaked, and somebody figures out that my username is rich0 and my password is gizmodo875.

          Does it do me any good that my slashdot password is slashdot875?

          This is why password aging is useless - if somebody finds the password of useless12 no longer works on a site that enforces aging they just have to log in using useless13 and that will work for 99% of accounts.

          • Yes and no. If it's a targeted attack against your specific account, then it makes sense to run through a set of likely possibilities (increment/decrement the digits in the password), but if the attacker just want to access accounts en masse, such as to send Twitter spam, then they likely won't bother if the login doesn't work on the first attempt.

            • by Rich0 ( 548339 )

              Well, the spammer is going to go for path of least resistance - he needs accounts and 500 is as good as 800 most likely.

              However, if by some miracle the advocates of stronger passwords get everybody to rotate passwords with numbers at the end, 5 lines of python on the attack scripts will be sure to try incrementing numbers at the end of each password when they get a failure.

      • by mgoff ( 40215 )

        What alternative do you propose?

        LastPass [lastpass.com]

        • by Rich0 ( 548339 )

          How do I use that on a work computer that I do not have admin rights to, and on which I'm forbidden by policy to install software on?

          Also - the website is hazy on how it manages synchronization - I'd prefer not to have to give some random service provider cleartext passwords to all of my accounts.

          Sure, password vault programs are a band-aid to a fundamental problem, but they are not a good solution.

      • by Xtense ( 1075847 )

        If you don't trust automated password keeper software and don't want to clutter your brain too much, just tier your passwords. Seriously. Have a set of five, maybe six levels of passwords with different levels of length and complexity. Lev1 on throwaway accounts you won't miss, Lev2 for accounts you don't use often but return once in a while, Lev3 for untrusted websites you need to use regularly, Lev4 for trusted sites containing no specific data, Lev5 for trusted domains with your private information, Lev6

        • by Xtense ( 1075847 )

          > Obviously, it goes without saying that you shouldn't ever write these down anywhere - and I mean everywhere.

          And this, dear Slashdotters, is why you should drink coffee before posting. Or just think before posting. ;]

        • > Bonus points if you change your passwords once in a while.

          I change my "Lev6" passwords now and again, and those are the only ones I write down -- because they DON'T have password recovery mechanisms.

          I write them down in my phone, which I keep on me at all times, and a trusted friend knows how to retrieve them in case I get killed.

          The reason I change them now and again is because I occasionally lose my phone... :/

      • One technique is to use a password that is a function of the website domain name. For example, all of your passwords could be the number of characters in the second level of the domain, a random string, and the first letter of the domain. For slashdot, the password would be "8RANDOMs". This won't protect against a person who knows your password, but it will stop a script that knows 44,000 username/password pairs and blindly submits them to websites.
      • What alternative do you propose? I must have accounts on 100 different websites by now, including this one. I can't create and remember 100 distinct strong username/password combinations on all of those websites. Unless you're an autistic savant you can't either.

        Keepass. Clients are available for all major platforms, desktop and mobile. Combined with Dropbox, I can add/change passwords to the database on any system and my other systems are updated. This includes my Android mobile phone. One could imp

        • by Rich0 ( 548339 )

          I like the concept behind keepass since it is open-source, but they seem to be missing a Chrome OS client.

          Wouldn't it be better to just use SSL or something like that, and get rid of passwords altogether? Granted, that requires every site on the internet to get more serious about security. I guess if we get enough worms it will eventually happen...

      • What alternative do you propose? I must have accounts on 100 different websites by now, including this one. I can't create and remember 100 distinct strong username/password combinations on all of those websites.

        Use one password. But from that password generate one-per site based on the domain name. All you have to remember is one password, the rest can be generated on demand. here you go [mozilla.org].

      • If you can't, then you're not thinking right.

        All you need is an algorithm to generate usernames and passwords based on website name. Perhaps something like ...

        mynameslashdot/slashdot1234abcd. ... that way, each site gets its own login ID and Password, but is EASILY remembered. Now of course that is a simplified example, yours should be more meaningful and unique, but just as easy for YOU to remember. That is something that a computer wouldn't be able to easily regress to a generic algorithm and then exploit

      • by xlotlu ( 1395639 )

        What alternative do you propose?

        Password Hasher: https://addons.mozilla.org/en-US/firefox/addon/3282/ [mozilla.org]

    • if they have the bad habit of using the same password everywhere...

      That's the problem. A server operator should ideally only have to manage access to his server. If he somehow leaks username-password pairs, then he should simply have to ensure that nobody gains unauthorized access to those accounts. Putting passwords used ELSEWHERE is just asking for trouble. For some reason I think about published interfaces to modules, and people using them in ways not documented, then having their code break when this u

  • Kudos to Mozilla (Score:5, Interesting)

    by duvel ( 173522 ) on Tuesday December 28, 2010 @05:27AM (#34684524) Homepage

    This is really well played by Mozilla. We are witnessing a prime example of crisis-communication. The basic rules are:
      - Communicate early (even if you don't have all the facts yet)
      - Communicate honestly (even if you're to blame)
      - Promise follow-up (as needed)
    Performing their crisis-communication this well will probably improve public perception of Mozilla. It will certainly raise the bar for other companies.

    • I disagree, mistakes like this should not happen at all.
      • by kestasjk ( 933987 ) * on Tuesday December 28, 2010 @06:05AM (#34684702) Homepage
        Here at slashdot we try to be supportive when tech companies make mistakes; we never kick people when they're down or make fun.

        Mozilla may not be our favorite tech company and we may not agree with their software development methodology; but damn it we're not going to treat them any differently, and will give them our support just like we would any down-on-their-luck company which made a silly one-off mistake!
      • by higuita ( 129722 ) on Tuesday December 28, 2010 @06:10AM (#34684718) Homepage

        it should not happen, but we are all humans (i think!!) and human people do mistakes (and scripts/robots break and fail by the way)

        all of us that administer servers have done some mistake in the past and probably will make more in the future. We can try to put enough road blocks to reduce the severity of the mistake, but they happen.

        so as "sh*t happens", the openness and honesty of mozilla is to praise, most close source companies would try to hide and ignore things like this.

      • Re: (Score:2, Insightful)

        by cbope ( 130292 )

        So, are you proposing that the offenders be drawn and quartered? Where are the torches and pitchforks?

        I mean come on, we are human after all and humans make mistakes. They have owned up to this mistake and you seem to want to make an example of them.

        But then, I suppose *you* have never made any mistakes. It must be great to live in a world that is so black & white.

      • by Opportunist ( 166417 ) on Tuesday December 28, 2010 @06:20AM (#34684754)

        No, they should not. But mistakes happen where humans are at work. The question is, how do these human then deal with the problems they caused?

        The usual is to hush-hush and hope nobody notices. Mozilla could have done just that, and with far better conscience than other companies who followed that practice. According to the logs, the file was downloaded once, and that's by the person that informed them about the mistake. Essentially, one could assume that this is as "safe" as it gets considering the blunder. If they just decided to shut up about it, probably nobody would have noticed.

        But is that the right way to deal with a problem that can potentially affect your customers?

        I quite strongly recommend NOT chewing them out for making a mistake but actually applauding their very considerate approach to dealing with it. Consider the "learning effect": Chew them out and the learning effect is that it's better to just hush up when you lose customer data, especially if the chance of it getting into the wrong hands is slim. That's pretty much what most other companies do, and even if it gets out it rarely causes more than a bit of a tempest in a teapot on /.

        Outside the security concerned tech community, nobody even notices.

        So yes, mistakes like that should not happen. But they do. They happened, they happen and they will happen as long as humans are somehow involved in the process. Hence I welcome how they dealt with it.

      • by jamesh ( 87723 )

        I disagree, mistakes like this should not happen at all.

        That's a given, but mistakes will happen, and did happen, and they did the right thing in response. Once the crisis is over i'm sure they'll look at what went wrong and how to stop it happening in the future, so stepping up onto a soapbox and saying "this should not happen" doesn't actually help. I think they already know that, and your attitude makes it _worse_ because potential hostility from people who don't understand this stuff might make companies think twice about reporting, and then we all lose.

        The

      • by Urkki ( 668283 )

        I disagree, mistakes like this should not happen at all.

        If you believe there are companies who haven't and/or will not do mistakes as bad as this, you're naive.

        So, when it's a given that mistakes like this happen, basically to every large organization, every once in a while, do you rather trust an organization that communicates about it, and you can be reasonably certain you know their screw up rate, or the one who tries to hide the mistake, and you don't know how many mistakes they've managed to hide already?

      • by mwvdlee ( 775178 )

        Wow, why didn't we all just think of that?
        All we need to do is be perfect; it's so simple!

        • I can't help but wonder if you people would be so forgiving and even apologetic if there was any sensitive information, like billing data, exposed by this mistake. I still don't see how they handled it well, or how they could have possibly handled it worse after the incident.
    • by McDee ( 105077 )

      No, the basic rules are:
            - Don't post sensitive user data on public sites

      The rest is damage limitation.

    • It is nice to hear them being honest, it is so annoying how most companies do not do this.

      I know of many examples from friends, family, and myself where we have irrefutable proof that a company has screwed up and what do we get every-time? Either the company does not respond or they say nothing is wrong.

      I wonder if some study has been done and it is actually better for companies to deny fault even when they know they are wrong.

    • Aren't they required by law to disclose any breach of private information, at least in the US? I don't know that this is as altruistic as it sounds.

  • But that doesn't excuse the fact they messed up in the first place. What mozilla have done is plain careless. I know, 'accidents happen' - but I'd rather they didn't and I don't trust companies not to keep making mistakes with user data.
    • by Opportunist ( 166417 ) on Tuesday December 28, 2010 @06:29AM (#34684790)

      Consider the consequences if it doesn't "excuse" it.

      Essentially, a company making a mistake has two choices: Hush it up or come forwards. Now, obviously the latter does not have any immediate benefit for them. It becomes known that they fucked up. Not good.

      Trying to cover it up has the nice effect that maybe nobody notices. And in this case, the chance of this happening was actually pretty high.

      If the net effect is the same, whether they cover it up or admit it, the choice is obvious. If I get accused of a crime and whether I plead not guilty (and hence force a lot of witnesses to testify and clog down the legal system) or guilty (and spare the witnesses to face me again, as well as running the whole process with far less waste of resources) has no effect on the verdict, nobody will plead guilty and confess anymore. Why should they? There's nothing to gain with it, is there?

      If you condemn a company making a mistake no matter whether they admit it or try to hide it, nobody will admit it anymore. And that can cause quite a bit more harm if that info gets into the wrong hands and hence your passwords get known by people who might abuse them, all because a company decided to play possum and you not knowing that your credentials have been compromised.

  • Seems like just yesterday I was deleting my Gizmodo account...

  • One more reason to (a) use fake names everywhere except your bank accounts and, (b) use a password safe application like KeePassX or LastPass to save unique passwords for every site you visit.
    This will minimize your exposure when something like this happens again at another site.

  • I applaud the timely and transparent response - and I admit I'm heavily biased in favour of (F)OSS.

    I've looked (quickly) but been unable to find details on how this was able to occur - do any Slashdot readers know? Could you post or point to the information please.

    This is all I could find out:-

    We have identified the process which allowed this file to be posted publicly and have taken steps to prevent this in the future. We are also evaluating other processes to ensure your information is safe and secure.

    Also - what, if any, steps are being taken to prevent it happening again?

    • I can see a few ways how this could happen. E.g. run the wrong copy batch, the "public" one instead of the "private" one. Maybe a careless drag and drop copying process (your finger never slipped from the mouse button?). There's so many ways to have a file end up where it should not be...

  • Are any of these users Massachusetts residents [slashdot.org]. :)
  • by kbg ( 241421 ) on Tuesday December 28, 2010 @07:31AM (#34685036)

    The day before this was noticed my Gmail account was hacked by Chinese spammers and I know I used the same password there. So I am skeptical about the claims that no one had downloaded this file. The email only says when they noticed the problem, but doesn't specify how long the file was available before that. It could have been available for a long time.

    • by mwvdlee ( 775178 )

      How do you know is was hacked by _CHINESE_ spammers?

      • by kbg ( 241421 )

        Because the IP used for the hack originated from China and the spam was advertising some chinese scam site where the bank account for the payments was a chinese bank.

        • by mwvdlee ( 775178 )

          I didn't know you could see the server logs from gmail.
          Any chance this might have been ordinary, random spam?

          • by kbg ( 241421 )
            No the spam was being sent from my account to all contacts in my address book. You can see Last account activity [google.com] in Gmail which reveals which IP addresses has accessed your account recently.
    • How old is your AMO account database entry? If it's newer than 2009, it's really unlikely they managed to crack the SHA-256.

      It's much more likely that your gmail account got cracked because Chinese hackers spend A LOT of effort in mass-cracking gmail accounts.

      • by kbg ( 241421 )
        It's older than 2009, so it was only MD5 which is easy to crack. The password was composed of random letters so I don't think it could have been mass cracked by brute forcing Gmail.
  • including email addresses, first and last names, and an md5 hash representation of user passwords."

    How long before we see a file on bittorrent?

    With plaintext passwords derived from crack MD5 hash representations.

    Time to change your password, if you have an account on Mozilla's website. Repeat with any other online resources (such as e-mail accounts or accounts with other websites) you used a similar password on.

  • This was likely someone doing a classic "select*fromusers" query. Hopefully this doesn't trip the sql injection filters :)

    If the hash had been in another table and that table had very restrictive permissions on it then this probably could have been avoided.

    The same problem is likely going to occur with databases that are being hit by Ajax calls or through some kind of proxy. If you don't want a column to make it's way out put it in a seperate table/db and restrict everyone but the key DBAs and web servers f

Trap full -- please empty.

Working...