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.
(Score: 4, Insightful) by bzipitidoo on Friday October 04, @01:24PM (9 children)
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)
>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)
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
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)
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)
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: 2) by JoeMerchant on Friday October 04, @09:58PM
> at least not by anyone competent building applications in this millenium.
Looking at you: x11vnc server https://en.wikipedia.org/wiki/X11vnc [wikipedia.org]
🌻🌻 [google.com]
(Score: 1, Interesting) by Anonymous Coward on Friday October 04, @05:37PM (1 child)
"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
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
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)
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)
$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)
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)
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)
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)
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)
(sorry for the off-topicness)
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by janrinok on Friday October 04, @08:28PM (5 children)
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)
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)
Aw damn! I couldn't find the pretzel.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by janrinok on Friday October 04, @08:45PM (2 children)
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)
I do appreciate you keeping an eye on that, thank you.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by janrinok on Friday October 04, @09:00PM
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
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
Is WhatsApp GDPR compliant yet?
(Score: 4, Interesting) by darkfeline on Friday October 04, @04:19PM (8 children)
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)
>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:
🌻🌻 [google.com]
(Score: 3, Insightful) by vux984 on Friday October 04, @10:36PM (3 children)
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)
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)
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
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)
So true, searching a stream for "&password=" is significantly sophisticated.
(Score: 2) by JoeMerchant on Friday October 04, @10:02PM
>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
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)
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
Heh! Sounds like "DROP TABLE" was a missed opportunity.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by quietus on Sunday October 06, @03:46PM
Maybe somebody should cc-to-all@facebook the article from which that quote was taken [acm.org].