Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 11 submissions in the queue.
posted by hubie on Friday October 04, @11:37AM   Printer-friendly
from the dumpster-fire dept.

https://arstechnica.com/security/2024/09/meta-slapped-with-101-million-fine-for-storing-passwords-in-plaintext/

Officials in Ireland have fined Meta $101 million for storing hundreds of millions of user passwords in plaintext and making them broadly available to company employees.

Meta disclosed the lapse in early 2019. The company said that apps for connecting to various Meta-owned social networks had logged user passwords in plaintext and stored them in a database that had been searched by roughly 2,000 company engineers, who collectively queried the stash more than 9 million times.
[...]
When Meta disclosed the lapse in 2019, it was clear the company had failed to adequately protect hundreds of millions of passwords.

"It is widely accepted that user passwords should not be stored in plaintext, considering the risks of abuse that arise from persons accessing such data," Graham Doyle, deputy commissioner at Ireland's Data Protection Commission, said. "It must be borne in mind, that the passwords, the subject of consideration in this case, are particularly sensitive, as they would enable access to users' social media accounts."
[...]
To date, the EU has fined Meta more than $2.23 billion (2 billion euros) for violations of the General Data Protection Regulation (GDPR), which went into effect in 2018. That amount includes last year's record $1.34 billion (1.2 billion euro) fine, which Meta is appealing.


Original Submission

This discussion was created by hubie (1068) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 4, Insightful) by bzipitidoo on Friday October 04, @01:24PM (9 children)

    by bzipitidoo (4388) on Friday October 04, @01:24PM (#1375697) Journal

    Plaintext passwords is a mistake that was largely ended in the 1980s and early 1990s. Hashing, salt, key stretching, the replacement of telnet with ssh, memory security measures such as zeroing out the RAM used by the password checker when it is done and making sure that memory is not paged out to a disk, all this stuff was available and pretty well standard practice by 2000.

    Mind, there are plenty of old systems still in use (2002 was when I was last asked to use telnet), but Facebook now, that was founded in 2004. There's just no excuse for such sloppy security.

    • (Score: 4, Insightful) by JoeMerchant on Friday October 04, @01:48PM (2 children)

      by JoeMerchant (3937) on Friday October 04, @01:48PM (#1375700)

      >Plaintext passwords is a mistake that was largely ended in the 1980s and early 1990s.

      It's not that it ended, it's that anybody who bothered to implement mid 80s best practices didn't do it anymore.

      There's two main reasons to not implement best security practices: ignorance and laziness. When an organization gets to significant size (say: more than one or two tech oriented staff), there can also be cultural headwinds that prevent those who are not ignorant from effectively communicating best practices into implementation throughout the organization - those cultural headwinds can also be summed up as: laziness in management.

      Educational requirements are supposed to address ignorance. In 1989 I took a Cryptography course as an optional part of my Masters' level computer engineering curriculum - it covered password hashing and the importance of not storing secrets in clear text, or even in recoverable form when possible, like most password applications. By now, that kind of information should be mandatory in any computer science curriculum, starting at high school level IMO.

      Significantly sized organizations should be required to hire a certain number of formally trained software engineers if they are going to be developing, or even re-selling password handling code developed by others. Ignorance is never an excuse and it certainly shouldn't be a defensible position since Jan 1, 2000.

      So, that leaves laziness - particularly in management. Laziness in management should be a culpable offense, liable to the damaged. Even if management doesn't have direct knowledge of security tech like password hashing / salting / etc. they should be hiring staff who does, soliciting best practice parameters from that knowlegable staff, and seeing that it is implemented. There's a huge range of damage possible in an exposed password, from zero to more than life-savings, per individual password revealed. Less than $1 per password revealed seems like a trivial slap on the wrist, to me.

      --
      🌻🌻 [google.com]
      • (Score: 3, Funny) by BeaverCleaver on Saturday October 05, @11:12AM (1 child)

        by BeaverCleaver (5841) on Saturday October 05, @11:12AM (#1375818)

        Well, Mark Zuckerberg is famous for dropping out of college. Maybe the "security" stuff was coming up for him next semester.

        • (Score: 2) by JoeMerchant on Saturday October 05, @01:13PM

          by JoeMerchant (3937) on Saturday October 05, @01:13PM (#1375824)

          Yeah, I'm sure Zuck coded the whole steaming pile with dropouts. It certainly functions that way.

          --
          🌻🌻 [google.com]
    • (Score: 2) by Username on Friday October 04, @05:02PM (2 children)

      by Username (4557) on Friday October 04, @05:02PM (#1375717)

      I wouldn't have cared too much either, if I were them. If someone was able to access the employee only share, that would mean they would have back end access, and could get the passwords, account info, change code, etc. Pointless to encrypt something when eveyone has access to the encrypt/decrypt mechanism.

      • (Score: 2, Insightful) by Anonymous Coward on Friday October 04, @06:11PM (1 child)

        by Anonymous Coward on Friday October 04, @06:11PM (#1375734)

        I wouldn't have cared too much either, if I were them. If someone was able to access the employee only share, that would mean they would have back end access, and could get the passwords, account info, change code, etc. Pointless to encrypt something when eveyone(sic) has access to the encrypt/decrypt mechanism.

        That's why passwords aren't stored in a way that they can be decrypted, at least not by anyone building applications in this millenium.

    • (Score: 1, Interesting) by Anonymous Coward on Friday October 04, @05:37PM (1 child)

      by Anonymous Coward on Friday October 04, @05:37PM (#1375720)

      "sloppy security" to some is malicious intent to others, not unlike the night watchman leaving the back door open. Somebody made a bundle from this.

      And this "fine"... embarrassing! If you want them to feel pain, take the gumball machine out of the office

      • (Score: 2) by Tork on Friday October 04, @05:53PM

        by Tork (3914) Subscriber Badge on Friday October 04, @05:53PM (#1375725)

        If you want them to feel pain, take the gumball machine out of the office

        How about: Executives must follow the same BYOD and WIFI rules the rest of the workers have to.

        --
        🏳️‍🌈 Proud Ally 🏳️‍🌈
    • (Score: 2) by DannyB on Friday October 04, @06:12PM

      by DannyB (5839) Subscriber Badge on Friday October 04, @06:12PM (#1375735) Journal

      Plaintext passwords is a mistake that was largely ended in the 1980s and early 1990s. Hashing, salt, key stretching

      The best way to not compromise a password is to never store it anywhere. We can't produce your password for you, because we keep no record of it.

      --
      Poverty exists not because we cannot feed the poor, but because we cannot satisfy the rich.
  • (Score: 5, Insightful) by Snotnose on Friday October 04, @02:06PM (13 children)

    by Snotnose (1623) on Friday October 04, @02:06PM (#1375703)

    They make so much money breaking or ignoring the law the fines are just a cost of doing business. It's time to toss some of Zuck's boardroom friends into jail for a while, see if that grabs their attention.

    --
    It's just a fact of life that people with brains the size of grapes have mouths the size of watermelons. -- Aunty Acid
    • (Score: 2) by JoeMerchant on Friday October 04, @03:18PM (12 children)

      by JoeMerchant (3937) on Friday October 04, @03:18PM (#1375705)

      $0.50 per password revealed isn't a fine, it's a joke.

      Just the personal cost of running around behind these clowns and updating your improperly handled sensitive info (password) should be compensated to the account holders at $5 per instance + any actual damages of the breach. That would run into the Billions.

      --
      🌻🌻 [google.com]
      • (Score: 2) by Tork on Friday October 04, @05:48PM (10 children)

        by Tork (3914) Subscriber Badge on Friday October 04, @05:48PM (#1375724)

        $0.50 per password revealed isn't a fine, it's a joke.

        I'd like to know what Facebook is paid when their 'sponsored posts' waft their way into my feed. The number of those seems to change every day....

        --
        🏳️‍🌈 Proud Ally 🏳️‍🌈
        • (Score: 2) by JoeMerchant on Friday October 04, @05:57PM (9 children)

          by JoeMerchant (3937) on Friday October 04, @05:57PM (#1375726)

          The classic, and true, answer is: it varies. From free taste promos up to multiple dollars per targeted impression for certain things. I think it's usually a few cents.

          --
          🌻🌻 [google.com]
          • (Score: 2) by Tork on Friday October 04, @06:08PM (8 children)

            by Tork (3914) Subscriber Badge on Friday October 04, @06:08PM (#1375733)
            That's actually more than I was thinking. Welp if they wanted to recoup that from me, even at 1 cent per, I'm like a day or two away from them putting it behind them. Their ad ratio is horrible.

            Tell ya what, I'll even do them a favor and not try any of their AI-generation tools. The power they save will make up for it super quick. :D
            --
            🏳️‍🌈 Proud Ally 🏳️‍🌈
            • (Score: 1, Offtopic) by janrinok on Friday October 04, @06:55PM (7 children)

              by janrinok (52) Subscriber Badge on Friday October 04, @06:55PM (#1375746) Journal
              Your sig has lost its colour.
              --
              I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
              • (Score: 1) by Tork on Friday October 04, @08:26PM (6 children)

                by Tork (3914) Subscriber Badge on Friday October 04, @08:26PM (#1375760)
                I'm not sure I understand. Do you mean it's showing up without the rainbow?

                (sorry for the off-topicness)
                --
                🏳️‍🌈 Proud Ally 🏳️‍🌈
                • (Score: 2) by janrinok on Friday October 04, @08:28PM (5 children)

                  by janrinok (52) Subscriber Badge on Friday October 04, @08:28PM (#1375761) Journal
                  Yes, didn't it used to be in colour?
                  --
                  I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
                  • (Score: 1) by Tork on Friday October 04, @08:40PM (4 children)

                    by Tork (3914) Subscriber Badge on Friday October 04, @08:40PM (#1375764)
                    Yes, and it is right now and it does show correctly on both Safari and Chrome. HOWEVER... I am on a Mac and I think Apple pays a little more attention than most at making emojis work. I think I have seen what you're describing, though, but I don't recall the circumstances. If I suss that out would you like me to let you know?

                    For the record I did find once that only some emojis work in the subject line when making posts, I've gotten it to reject the post before. I remember thinking it wasn't the emoji, it was that it was one of the more recent ones. I just assumed the identifier has a limit or something. Heh now I'm starting to wonder if the search feature will find emojis. 🥨

                    ps sorry if i went too far off-topic... um... does plain text include emojis? 🤡
                    --
                    🏳️‍🌈 Proud Ally 🏳️‍🌈
                    • (Score: 1) by Tork on Friday October 04, @08:41PM (3 children)

                      by Tork (3914) Subscriber Badge on Friday October 04, @08:41PM (#1375765)

                      No comments were found that match your query.

                      Aw damn! I couldn't find the pretzel.

                      --
                      🏳️‍🌈 Proud Ally 🏳️‍🌈
                      • (Score: 2) by janrinok on Friday October 04, @08:45PM (2 children)

                        by janrinok (52) Subscriber Badge on Friday October 04, @08:45PM (#1375766) Journal

                        I'm not too concerned if you are not - other emojis on other sigs are still showing in colour so I don't think it is a bug at this end.

                        --
                        I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
                        • (Score: 1) by Tork on Friday October 04, @08:55PM (1 child)

                          by Tork (3914) Subscriber Badge on Friday October 04, @08:55PM (#1375769)
                          I concur. I don't blame you for asking, though. We're a few days out from big OS updates from Apple and, for reasons I don't understand, that always includes Safari silliness. (Im encountering a couple of bugs on a daily basis and don't expect a fix soon... sigh.)

                          I do appreciate you keeping an eye on that, thank you.
                          --
                          🏳️‍🌈 Proud Ally 🏳️‍🌈
                          • (Score: 2) by janrinok on Friday October 04, @09:00PM

                            by janrinok (52) Subscriber Badge on Friday October 04, @09:00PM (#1375771) Journal

                            The bug is reproducible. It is a Brave/Chrome issue. Other browsers are working fine.

                            --
                            I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
      • (Score: 2) by aafcac on Friday October 04, @10:33PM

        by aafcac (17646) on Friday October 04, @10:33PM (#1375781)

        That's probably something similar to what it costs to send out a letter informing all the impacted individuals that their account has been compromised.

  • (Score: 3, Interesting) by PiMuNu on Friday October 04, @03:20PM

    by PiMuNu (3823) on Friday October 04, @03:20PM (#1375707)

    Is WhatsApp GDPR compliant yet?

  • (Score: 4, Interesting) by darkfeline on Friday October 04, @04:19PM (8 children)

    by darkfeline (1030) on Friday October 04, @04:19PM (#1375712) Homepage

    Meta did not store passwords in plaintext. At least, not in the way that an average engineer would interpret that statement, so the statement is misleading, even if technically correct. This is the kind of thing an actual, competent journalist would not do (but of course, very few of those exist nowadays, especially at outlets such as Ars Technica it seems).

    They logged passwords. Which is a rather incompetent mistake, but quite a few levels above the level of incompetence being implied. Filtering secrets out of logs requires significantly more sophistication than not "storing passwords in plaintext"; a college student could reasonably be expected to learn and implement the latter, but not the former.

    --
    Join the SDF Public Access UNIX System today!
    • (Score: 2) by JoeMerchant on Friday October 04, @05:00PM (4 children)

      by JoeMerchant (3937) on Friday October 04, @05:00PM (#1375716)

      >Filtering secrets out of logs requires significantly more sophistication

      Funny you should say that. We have a compile time flag "BUILT_FOR_PRODUCTION_USE" which must be present for any code that is in production use. The significant sophistication we use to keep passwords and all protected information out of log files is:

      #ifndef BUILT_FOR_PRODUCTION_USE
      log message with whatever the hell tickles your fancy, including passwords
      #else
      log message with only non-sensitive information
      #endif

      --
      🌻🌻 [google.com]
      • (Score: 3, Insightful) by vux984 on Friday October 04, @10:36PM (3 children)

        by vux984 (5045) on Friday October 04, @10:36PM (#1375783)

        It's not THAT simple.

        A pretty basic example is an HTTP request logger at the edge of an application. It might front the entire service; logging API requests and responses.

        It doesn't know the structure of the json/soap/xml/whatever that is every request or response.

        Hell it might not even be part of your application; it be a proxy service running in front your application, administered by a completely different team.
        It might even be managed by a different company as part of web-application-firewall / intrusion detection system / service completely unrelated to the application.

        • (Score: 2) by JoeMerchant on Friday October 04, @11:41PM (2 children)

          by JoeMerchant (3937) on Friday October 04, @11:41PM (#1375790)

          So, the password is transiting to and from uncontrolled software in the clear? Yeah, fixing the logs should be pretty far down the list.

          --
          🌻🌻 [google.com]
          • (Score: 3, Insightful) by vux984 on Saturday October 05, @07:28PM (1 child)

            by vux984 (5045) on Saturday October 05, @07:28PM (#1375875)

            The password is inside an HTTPS request. The proxy front end web application firewall (WAF) is configured with the public facing SSL certificates. The connection from browser to WAF is in the HTTPS connection. The connection from the WAF to the backend, is possibly a VPN, or another HTTPS session, or even just forwarded on to the backend using the same SSL certificates depending on the architecutre. Either way its not "in the clear" per se, but it is definitely available in-the-clear on the WAF and can easily be inadvertently written out to the log files there, so what you think seem to think is entirely poor design -- is how the entire web works.

            Or are you saying the password shouldn't be sent inside the HTTPS request to the server at all? In which case, what are you talking about?
            Take a look at your login request to soylentnews...

            op: "upserlogin"
            unickname: "vux984"
            upasswd: "yep, there it is"
            userlogin: "Log+in"

            Or maybe you think soylent is a low tech old backwards system... so how about an AWS console..

            account: "...."
            username: "..."
            password: "yep, there it is"
            client_id "arn:aws:signin::console/canvas"

            Ok... how about bitwarden...a zero knowledge password manager

            scope: "api offline_access"
            client_id: "web"
            deviceType: "10"
            deviceIdentifier: "..."
            deviceName: "firefox"
            grant_type: "password"
            username: "...."
            password: "oooh -- they HASHED it -- good on them"

            But lets stop and think about that for a moment -- yes they hashed it to send it to the server, which is a nice little extra step, so my plaintext passphrase isn't sent to the server. But its a pretty small win. Because this hash value they're sending up IS JUST AS SENSITIVE A VALUE THE PLAINTEXT PASSWORD!!

            (Aside: presumably server side, they then hash it again to compare it to another hash in the database to actually login. Like you would normally do with a password.)

            But meanwhile, yes, you can fire up postman or insomnia or whatever, and simply send the hash up to the server, or add a client-side browser script hack to bypass the local hashing so it just forwards the password input directly and then use this hash value AS THE PLAINTEXT PASSWORD, because that's what it is.

            Bottom line, if you know this hash that is being sent over the wire, then you can sign into my bitwarden account without actually knowing my passphrase. So this hash is, for all intents and purposes, my plaintext password.

            And writing this hash to a log somewhere is pretty much just as bad as writing my plaintext password to the log. As anyone who gets their hands on the logs can sign into my account with it.

            So what is bitwarden accomplishing by hashing it before sending it exactly? Very little. The only benefit I can think of to hashing it before I send it to the server is: in the event that the hash is somehow captured, the attacker can get into my bitwarden account, but I won't be vulnerable to a password-reuse attack on another site. (Of course... the attack can get into my bitwarden account ... so they aren't really going to need to take advantage of password reuse. :) That's not much of win, especially in this case.

            Can imagine some other advantage?

            • (Score: 3, Interesting) by JoeMerchant on Saturday October 05, @08:43PM

              by JoeMerchant (3937) on Saturday October 05, @08:43PM (#1375885)

              So, yes, the password has to transit to the authenticator in a recoverable form (unless we hatch a new protocol which challenges with a salt and the client responds with the hash for that salt+pass).

              My argument is, all these "walled gardens" inside their https/VPN cello-wrap should not be exposing secrets willy nilly to every log4j and other half baked tool just because they are inside the "trusted zone". OAUTH2 seems to address this somewhat, and all the talk of "zero trust" is good rhetoric, but if current state of the art is still logging the whole freshly decrypted stream, that current state is pretty sad.

              Our (not really web facing) product logs any and all clear text traffic as desired, but the encrypted messages' info fields are specifically NOT logged until they have been identified and classified as not sensitive information. If we don't do that, we open up a world of hurt in the handling of those potentially sensitive log files.

              Of course, the user facing screens sometimes contain sensitive information too, and we do have "screenshot," functionality... That gets to be a grey area, we generally charge the users with responsibility for proper handling of screen images (which, even with our built in digital capture method, people still end up snapping cell phone images and videos all the time....

              --
              🌻🌻 [google.com]
    • (Score: 0) by Anonymous Coward on Friday October 04, @09:11PM (2 children)

      by Anonymous Coward on Friday October 04, @09:11PM (#1375774)

      So true, searching a stream for "&password=" is significantly sophisticated.

      • (Score: 2) by JoeMerchant on Friday October 04, @10:02PM

        by JoeMerchant (3937) on Friday October 04, @10:02PM (#1375778)

        >searching a stream for "&password=" is significantly sophisticated.

        Yeah, it's right up there with a properly salted SHA3-256 validation algorithm (not.)

        Though, I will grant, it does take a little more vigilance to find all the potential leaks.

        --
        🌻🌻 [google.com]
      • (Score: 2) by vux984 on Friday October 04, @10:42PM

        by vux984 (5045) on Friday October 04, @10:42PM (#1375786)

        Genius! And what if some backend dev names a parameter containing a password to: "parameter_b" and neglects to mention it to team managing the logging stream writer?

  • (Score: 3, Touché) by DadaDoofy on Friday October 04, @05:10PM (1 child)

    by DadaDoofy (23827) on Friday October 04, @05:10PM (#1375718)

    While I never thought anyone would be dumb enough to do this, I have always held out hope it was the case, especially if employees are reading them. My password starts with "FuckZuck".

    • (Score: 3, Funny) by Tork on Friday October 04, @05:47PM

      by Tork (3914) Subscriber Badge on Friday October 04, @05:47PM (#1375722)

      While I never thought anyone would be dumb enough to do this, I have always held out hope it was the case, especially if employees are reading them. My password starts with "FuckZuck".

      Heh! Sounds like "DROP TABLE" was a missed opportunity.

      --
      🏳️‍🌈 Proud Ally 🏳️‍🌈
  • (Score: 2) by quietus on Sunday October 06, @03:46PM

    by quietus (6328) on Sunday October 06, @03:46PM (#1375978) Journal

    The 6.5 million hashed passwords in all likelihood represent far more users than that, because everybody who chose "qwer5678" as a password shares a single entry in that file. I wouldn't be surprised if 6.5 million was the number of unique passwords all LinkedIn users have chosen, as there is, after all, only so much imagination to go around.

    Maybe somebody should cc-to-all@facebook the article from which that quote was taken [acm.org].

(1)