I almost guarantee this is some logging system configured to "just log every request" or "just keep the innerHTML of the whole page whenever an error occurs for debugging" or similar, which picked up password fields too.
Absolutely many people must have noticed. It was either technically infeasible to encrypt those (doesn't seem likely). Or the business decided it wasn't worth the investment (more likely).
This is why I always hash passwords client side before sending them to my servers. That way, when I store them in plain text, I can say it is just the hash and not the password itself!
On a relevant note, how is this fine amount determined? Were there any damages?
Can't tell if your being sarcastic or not. Now your hashes are just the passwords. Your server can't unhash them, so anyone intercepting your traffic effectively has the password.
I was being sarcastic, but, why wouldn't client-side hashing of passwords prevent some class of attacks that can be used when plaintext passwords are accidentally stored(and eventually exfiltrated) - eg credential stuffing?
Because you've just changed what the password is. For example if your password is X, with hash Y, the server identifies Y as your password. Then I come along and steal Y. The server has no concept of X, so to the server you and I are equally valid in being you. We both present the hashed password Y.
Isn't there still an advantage of hash Y is now known and is like abcd1234 while the password X (hunter2) remains unknown?
So while you can still authenticate as the user to say facebook you can't login to their linkedin account. Assuming, facebook and linkedin don't use the same client side salt.
But you gain the downside that if your password database gets leaked, now every users' password is there in plaintext. All you have to do is bypass the hashing function in the client-side login so you can send whatever hash you have in your database leak.
You could hash them again before they hit db, but then your not really pre-hashing the passwords clientside. And if you want to change your hashing algorithm or parameters, users can't login until they update their clients.
I mean this sounds like a "you'll never have a bug if you just program well" argument.
Whoever created the login system probably is a different person than who added the logging system. Perhaps the logging system should've discarded login attempts or masked the credentials but there's probably a dozen ways to login and they'd need to know all of them and possible futurely added ones.
It seems a bit more practical to have the system send a safer version of a parameter to the server instead.
Clearly "Y" is just the password as my server sees it
But, by not sending the actual user-entered password, it prevents me from logging the user-entered password in plaintext.
If I did make a mistake and logged the users email and "Y", and I got hacked, the hacker could not take the email and "Y" and try to log into a variety of other online services using the same credentials. This is the credential stuffing I was speaking of.
There are people who just append password with the name of site or something relevant to site. Like "mypasswordfb". It would prevent guess google's password as "mypasswordgoogle"
They have never been specific about it but everything about this story suggests that the "storage" in question was logs. It is easy to accidentally create a system that logs passwords as a side effect of logging some request along with its parameters, and it takes structure and discipline to avoid it.
Guys, it is very difficult to avoid logging clear text passwords if your systems are set up to compile auditable logs of anything, and you already know why.
Because people will constantly enter their passwords in the wrong places, that's why. Classic Unix systems administrators always found passwords logged as usernames. Or in shell history files. Or on typescript transcripts.
Facebook's forms are no different, and all it takes is a moment of inattention, type into the wrong field, an accidental copy-paste, or an overzealous password manager, and how many millions of users will eventually send in their passwords?
The truly marvelous technical feat would be to devise a way to stop this. Essentially, you couldn't. It's a complex issue. Not negligence.
they should prove damages before setting fines like this.
the american gov is spending billions upon billions to defend the eu and they have the gall to nitpick & set 7 to 9 fig fines using %revenue (extortion) on their companies, which are btw providing valuable services (for free) to eu citizens. beyond ridiculous, especially with no sensible cap on the fines.
all the gdpr has done is make the web more miserable, someone from the usgov should give a call to the data protection office or wtv to remind them of their actual importance in the grand scheme of things.
and this is ignoring the damage they're doing to their own tech ecosystem with this over-regulation.
The profit Meta et al make just appears out of thin air. It's so kind of these companies to use the income they get from their money trees to altruistically provide free services to anyone.
Jokes aside: The cost may be hidden, but you're still the one who pays.
> all the gdpr has done is make the web more miserable
For those in the US? Perhaps, at least if we only look at the direct impact.
In the EU it made all sorts of privacy abuse that's completely standard and accepted in the US (credit agencies, payroll companies, etc. etc. sharing all sorts of information with anyone who asks/pays in addition to online tracking) legally impossible.
discussed previously: https://news.ycombinator.com/item?id=41669912
Thanks! Macroexpanded:
Meta fined $102M for storing passwords in plain text - https://news.ycombinator.com/item?id=41678840 - Sept 2024 (119 comments)
Meta pays the price for storing passwords in plaintext - https://news.ycombinator.com/item?id=41677465 - Sept 2024 (6 comments)
Meta pays the price for storing passwords in plaintext - https://news.ycombinator.com/item?id=41674082 - Sept 2024 (7 comments)
EU privacy regulator fines Meta 91M euros over password storage - https://news.ycombinator.com/item?id=41669912 - Sept 2024 (38 comments)
I almost guarantee this is some logging system configured to "just log every request" or "just keep the innerHTML of the whole page whenever an error occurs for debugging" or similar, which picked up password fields too.
Super easy mistake to make.
I’m not sure how it’s even possible to store plaintext passwords in 2024, don’t most systems use a base level of encryption by default?
Also surely someone noticed before they had to be fined, yikes
They realized in 2019. I'm assuming it wound up in logs somewhere and someone went "why the heck am I seeing prod passwords?"
Absolutely many people must have noticed. It was either technically infeasible to encrypt those (doesn't seem likely). Or the business decided it wasn't worth the investment (more likely).
Logs.
This is why I always hash passwords client side before sending them to my servers. That way, when I store them in plain text, I can say it is just the hash and not the password itself!
On a relevant note, how is this fine amount determined? Were there any damages?
Can't tell if your being sarcastic or not. Now your hashes are just the passwords. Your server can't unhash them, so anyone intercepting your traffic effectively has the password.
I was being sarcastic, but, why wouldn't client-side hashing of passwords prevent some class of attacks that can be used when plaintext passwords are accidentally stored(and eventually exfiltrated) - eg credential stuffing?
Because you've just changed what the password is. For example if your password is X, with hash Y, the server identifies Y as your password. Then I come along and steal Y. The server has no concept of X, so to the server you and I are equally valid in being you. We both present the hashed password Y.
Isn't there still an advantage of hash Y is now known and is like abcd1234 while the password X (hunter2) remains unknown?
So while you can still authenticate as the user to say facebook you can't login to their linkedin account. Assuming, facebook and linkedin don't use the same client side salt.
But you gain the downside that if your password database gets leaked, now every users' password is there in plaintext. All you have to do is bypass the hashing function in the client-side login so you can send whatever hash you have in your database leak.
You could hash them again before they hit db, but then your not really pre-hashing the passwords clientside. And if you want to change your hashing algorithm or parameters, users can't login until they update their clients.
Yes, it’s an advantage if you plan to store plain text, but storing plain text is bad to begin with.
There is no advantage if you use proper security practices like storing a hash and salt.
I mean this sounds like a "you'll never have a bug if you just program well" argument.
Whoever created the login system probably is a different person than who added the logging system. Perhaps the logging system should've discarded login attempts or masked the credentials but there's probably a dozen ways to login and they'd need to know all of them and possible futurely added ones.
It seems a bit more practical to have the system send a safer version of a parameter to the server instead.
Clearly "Y" is just the password as my server sees it
But, by not sending the actual user-entered password, it prevents me from logging the user-entered password in plaintext.
If I did make a mistake and logged the users email and "Y", and I got hacked, the hacker could not take the email and "Y" and try to log into a variety of other online services using the same credentials. This is the credential stuffing I was speaking of.
There are people who just append password with the name of site or something relevant to site. Like "mypasswordfb". It would prevent guess google's password as "mypasswordgoogle"
$101M for a problem from 5 years ago, fixed quickly with no harm done to anybody, with users notified immediately at the time.
I wonder how much of a fine Ireland would have levied on an Irish company in similar circumstances.
Probably less because there aren't many companies of Irish origin with a worldwide annual revenue that's as high as Facebook's.
(See also https://news.ycombinator.com/item?id=41675507)
This Ireland you speak of makes the foreign Meta Platforms much more money in tax avoidance/evasion.
Side effect of "move fast and break things", which is why the slogan has been changed to "move fast with stable infrastructure" (not kidding)
[dupe] you new here?
More discussion: https://news.ycombinator.com/item?id=41669912
https://news.ycombinator.com/item?id=41678840
If you don’t want to deal with the headaches and complexities of actual encryption, base64 at least gets you some level of information hiding.
They have never been specific about it but everything about this story suggests that the "storage" in question was logs. It is easy to accidentally create a system that logs passwords as a side effect of logging some request along with its parameters, and it takes structure and discipline to avoid it.
Guys, it is very difficult to avoid logging clear text passwords if your systems are set up to compile auditable logs of anything, and you already know why.
Because people will constantly enter their passwords in the wrong places, that's why. Classic Unix systems administrators always found passwords logged as usernames. Or in shell history files. Or on typescript transcripts.
Facebook's forms are no different, and all it takes is a moment of inattention, type into the wrong field, an accidental copy-paste, or an overzealous password manager, and how many millions of users will eventually send in their passwords?
The truly marvelous technical feat would be to devise a way to stop this. Essentially, you couldn't. It's a complex issue. Not negligence.
This isn't substantial money for Meta, is it?
It's a little less than 0.3% of their earnings for a single quarter, so no, not at all.
Seems like a card to remind people to be careful when developing systems.
they should prove damages before setting fines like this.
the american gov is spending billions upon billions to defend the eu and they have the gall to nitpick & set 7 to 9 fig fines using %revenue (extortion) on their companies, which are btw providing valuable services (for free) to eu citizens. beyond ridiculous, especially with no sensible cap on the fines.
all the gdpr has done is make the web more miserable, someone from the usgov should give a call to the data protection office or wtv to remind them of their actual importance in the grand scheme of things.
and this is ignoring the damage they're doing to their own tech ecosystem with this over-regulation.
> for free
The profit Meta et al make just appears out of thin air. It's so kind of these companies to use the income they get from their money trees to altruistically provide free services to anyone.
Jokes aside: The cost may be hidden, but you're still the one who pays.
> all the gdpr has done is make the web more miserable
For those in the US? Perhaps, at least if we only look at the direct impact.
In the EU it made all sorts of privacy abuse that's completely standard and accepted in the US (credit agencies, payroll companies, etc. etc. sharing all sorts of information with anyone who asks/pays in addition to online tracking) legally impossible.