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.
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.
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).
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 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.
It's obviously bad, but mistakes happen. We're in a thread about meta, one of the largest tech companies in the world, making this exact mistake with millions of accounts.
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 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.
reply