FTC Fines RockYou $250,000 For Storing User Data In Plain Text 127
An anonymous reader writes "You probably don't remember the RockYou fiasco as it happened in late 2009. In case you don't, social game developer RockYou suffered a serious SQL injection flaw on its flagship website. Worse, the company was storing user details in plain text. As a result, tens of millions of login details, including those belonging to minors, were stolen and published online. Now, RockYou has finally settled with the Federal Trade Commission."
Re: (Score:2, Funny)
We will
We will
Rock You!
We will
We will
Fine You!
Re: (Score:2)
Re: (Score:3)
A new bel-air for a new age?
Re: (Score:2)
God, no! [sj-r.com]
Re: (Score:2)
So, when's Sony getting fined for storing data in the clear as exposed in the PSN and LulzSec breaches?
Re: (Score:2)
They never stored any data in plain text. The incident you're likely referring to was a PSN user that had installed custom firmware on his PS3. The CFW was purposely designed to steal credit card info and transmit it back in plain text.
Passwords!? (Score:5, Interesting)
What? (Score:2)
Colonel Sandurz: 1-2-3-4-5
President Skroob: 1-2-3-4-5?
Colonel Sandurz: Yes!
President Skroob: That's amazing. I've got the same combination on my luggage.
Plain text (Score:5, Informative)
I suspect that whilst websites have user/password control, and whilst it is common to encrypt passwords in a database, most other database records are mostly in plain text
Seems silly (Score:5, Informative)
So just want that out there: There are some limited cases where storing login credentials in the clear is a necessity. But that's no excuse for not sanitizing the data... SQL injection attacks are stupidly easy to prevent, and the web designer who wrote the code that allowed it should probably be censured. If you're going to fine a company -- fine them for the injection attack... but leaving data in plain text is not a problem per se.
Layers of problems. (Score:1)
Having the passwords in the clear would not be a problem if their servers were not so stupidly vulnerable.
Stupidly vulnerable servers being the result of stupid admin/programmer.
Stupid admin/programmer being the result of management that does not understand computer security.
Etc, etc, etc.
There are always a thousand reasons NOT to correctly handle basic computer security. Time, money, resources, training, blah, blah, blah. And there always will be. Which is why this type of incident will play out over and o
Re: (Score:2)
f you're putting a server on the Internet and you have NOT solved the problem of hashing the passwords then there is a core problem that has not been addressed. Something is wrong with your business model or programmer or management or whatever.
Not necessarily. If your website depends on impersonating you via login credentials to a third party, then without that website's cooperation, the login information is going to have to be stored in the clear. That was my only point: The headline and article indicates the FTC fined them because that information was stored in the clear, not gross negligence on the part of the web designer and company which allowed that information to be leaked. That is what the FTC should be punishing: Lack of code auditing,
Re: (Score:2)
And after the first fine of $250,000 for losing passwords stored in the clear that entire system is going to be re-evaluated.
Re:Layers of problems. (Score:5, Informative)
... and if they HAD known that they'd be slapped with a $250,000 fine for it they would have done it different.
I'm not convinced. A few years ago I came across a curious story about how companies dumping toxic waste into the ocean were filming themselves doing it and then attaching a check to the EPA for the fine without being contacted by the agency. As it turns out, the cost for disposing of the materials at sea was less than the cost of disposing of it properly even when the fine was assessed for every infraction -- by a considerable margin.
So from that I learned that while a fine might seem large to me ($250,000 is not pocket change to me!), in a business sense it could mean next to nothing, or even be preferable to 'doing it right'.
As well, the cost of that fine will not be borne by the people in charge of causing this train wreck: It will be the people who use the product. As long as there is no individual accountability, the system is fundamentally flawed -- those people can keep right on doing what they are doing, and the company will absorb and dissipate the responsibility and costs of doing so, often with impunity. Fines/punishments should only ever be levelled against the individuals responsible, which provides much greater assurances of competency and ethics than fining a company.
Let me try a different way. (Score:2)
Would you be able to build a system as you described (impersonating you via login credentials to a third party) AND have that system use only hashed passwords?
I could and my programming skills suck.
My point being that hashing passwords does not violate any laws of physics. If they built the system in such a way that it required clear text passwords then that was a decision that they made based off of their limitations and such.
Re: (Score:2)
I could and my programming skills suck.
So does your reading comprehension. Say you login to Facebook. Okay. Login complete. One way hash is fine. Now say, Facebook had a feature where it would check your gmail account for you, just provide the password. So you provide it with your gmail account password. Now how the hell is Facebook going to login to your gmail account if it doesn't have the plain text password?
Re: (Score:2)
That's a poor example - Gmail supports OAuth. Slashdot would be a better example, as it doesn't support protocols and technologies invented after 1992.
Re: (Score:2)
Not really. The point is that whatever token - whatever token - you need to hand to the remote server to establish your bone fides has to be available in a form that the remote server will accept. That means no one-way hashing, period.
Sure, with OAuth a compromise won't reveal your actual password, which will keep it out of the hands of scripts designed to spread the pain. That's good, really good. But it won't mean that somehow, magically, your GMail account won't get hacked.
Okay, you're an idiot. (Score:2)
Yeah, you might want to look up what "third party" means because you don't seem to understand that it means exactly what you just posted.
Simple, encrypt it and store the enc
Re: (Score:2)
Re: (Score:2)
I don't think you understood what "impersonating you via login credentials to a third party" means. The solution you propose requires you to have a "master" account in the third party system that lets you access all your user's account in that third party system.
The issue here is when the only way to authorise an action is by using your username/password. In this case, if you want someone else to do something on your behalf (say, post to twitter before twitter implemented oauth), you need to give your usern
How eBay handles applications (Score:2)
Re: (Score:2)
So essentially you wish to ELIMINATE the corporate veil.
California has almost done that. Wonder why people would rather incorporate in Nevada (which strongly respects the corporate veil) vs California? That, right there!
Re: (Score:1)
So essentially you wish to ELIMINATE the corporate veil.
It never should have existed in the first place. Sovereignty is reserved for countries, not corporations.
Re: (Score:2)
Encrypt with what key? (Score:2)
simply encrypt the data instead of hashing it
With what key? The application accessing the database needs the key in order to encrypt or decrypt text, and anyone with physical or otherwise administrative access can retrieve that key.
Re: (Score:2)
Ideally, they should store the user data encrypted with a random key (and salt, of course, so one user's files that have the same contents can't be told from another.) That random key is stored encrypted with either the data from recovery questions, or the user's password able to unlock it, neither available/recoverable from the stored, salted hashes. Of course, if the user chooses crappy recovery answers, an attacker would have it easy to unlock items, but that form of security is up to the user.
Re: (Score:2)
There are perfectly legitimate reasons to maintain user account information in the clear
Personal user information? SS Numbers, addresses? Really?
Re: (Score:2)
There are perfectly legitimate reasons to maintain user account information in the clear
Personal user information? SS Numbers, addresses? Really?
Sure. Just off the top of my head: an employer would need to keep social security numbers and addresses in the clear for tax purposes, as would pretty much any entity involved with financial transactions.
Yes, the information could be encrypted in the database but the key would need to be accessible if users are able to view and edit their stored information or if the company needs to file tax-related information. This is essentially the same as keeping the information in the clear.
Re: (Score:2)
There are one-way encryption methods (for example, MD5, SHA1) which only allow you to encrypt a string, but not decrypt it. There are also two-way encryption schemes (allows encryption and decryption), like AES Encryption. [mysql.com] If I had to store data which could identify users or credit card information, I would look into two-way encryption mechanisms (those which can be both encrypted and decrypted).
More info on using AES to store credit card info [stackoverflow.com].
The theory behind these algorithms is quite involved, but the p
Re: (Score:2)
[detour]I always hesitate to call MD5 and SHA1 "encryption methods" instead of [cryptographic] hashes, but then I remember certain bank whose definition of hashing the user's password is to replace each letter with the corresponding number on a phone's keyboard. That is worse than using no encryption at all.[/detour]
The problem with using AES or any other symmetric ciphers is that it merely turns the problem into a key management problem... it just relocates it, not solves it. Now instead of having to keep
Re: (Score:2)
Re: (Score:2)
> There are perfectly legitimate reasons to maintain user account information
> in the clear: Namely, that you can't one-way hash anything except the login
> credentials and have it remain useful.
There is a middle ground between plain-text and one-way hashes: it's called "encryption" and it's just like a one-way hash except it's two-way.
Re: (Score:1)
None of this makes sense when you're talking about a SQL injection or other service compromise. No matter how may ways you encrypt stored values, if it is made available in decrypted form for normal system function (e.g. to display any of the data back to a user, or to calculate other results), then a compromised service can reveal that decrypted form too. Worrying about whether it was encrypted or not only makes sense if someone stole the server disks out of the datacenter, without stealing the entire ma
Re: (Score:2)
Re: (Score:2)
For sites not supporting OAuth (Score:2)
Re: (Score:2)
Since the GP was referring to "anything except the login credentials".
Re: (Score:2)
There are many types of possible exploits. Maybe someone gets an SQL dump but since it doesn't run through the regular method it doesn't get decrypted on the fly. Security in layers, my friend. No single setting will prevent all bad things from happening, so you protect against different exploits in different ways. It doesn't hurt to have additional measures. It's not like there's some rule that says "You're only allowed to protect this data in one way."
Re: (Score:1)
under what conditions would you consider storing a password as clear text not a bad idea?
Re: (Score:2)
Re: (Score:2)
Under a requirement to pass this password to a third party when "linking accounts" (that is, making requests of the third party on the user's behalf). It could be stored encrypted in the database, but with what key?
If the user is passing a clear-text password, you could use that as the key for their other passwords. Use your stored hash to validate their password, use their password as the key for their third-party data.
If the user-agent is passing a hashed password, use a different hash as the key for third-party data. Send both hashes to the server, which uses one for authentication and the other for decryption of the third-party data.
Re: (Score:2)
If the user is passing a clear-text password, you could use that as the key for their other passwords. Use your stored hash to validate their password, use their password as the key for their third-party data.
How would this password, which is the key for their third-party data, be securely stored between the moment the user logs in and several minutes later when the user needs to have the server fetch a resource from a third party?
Re: (Score:2)
It wouldn't be all that secure in-memory, but an SQL injection attack won't reveal it. It's marginally more secure. I was merely answering the question about what a potential key to that field in the database would be.
Re: (Score:2)
It wouldn't be all that secure in-memory, but an SQL injection attack won't reveal it.
It would if sessions are stored on disk so that everyone isn't kicked out on an occasional planned reboot.
Re: (Score:2)
Yes, of course, but that would be a pretty bad design. If some third-party is storing my credentials, I'd rather have to re-authenticate when they plan maintenance than have them store sensitive data unencrypted on disk.
Re: (Score:2)
Re: (Score:2)
I would say no, putting sensitive data on a machine that's shared with others is a bad practice no matter how you do it.
Re: (Score:2)
That's what civil suits are for. The FTC just enforces applies fines.
Hmmm (Score:3, Insightful)
Re: (Score:2)
Was Sony violating COPPA too?
EA had better watch out. (Score:2)
Last time I forgot my password, their "lost password" page emailed it to me in plaintext...
Re: (Score:1)
Most of the "forgot password" features out there really aren't secure. I have poked holes in most of the methods I've found. I think that's just the way it is. To make it really more secure would decrease the convenience to very low levels and just piss users off.
Reasons to store in plaintext (Score:5, Funny)
* Some users like to be reminded of their password if they forget. If you lost your password, what kind of email would you rather get?
"Your password has been reset, and your new password is dFgk3b&4k72"
or,
"Your password is iloveyou123"
* You might decide to fire up phpmyadmin and browse the `users` table for fun one day.
* If you're going to hash the passwords, you should salt it too, and that just introduces too much complexity and things to screw up. Keep it simple!
* Your boss doesn't know what a hash is, why should you?
Re:Reasons to store in plaintext (Score:5, Funny)
Re: (Score:1)
There are many masochists, as evidenced by the fact that they use PHP at all.
Re: (Score:2)
There are existing functions and methods to do these things in all variations of web programming, as well as backend server code, even in C. There is zero excuse NOT to do big salted hashes.
Of course, if the server is compromised, the malware can capture the plaintext passwords as users submit them. Passwords for inactive users generally tend to be of less value, anyway.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
This is not even remotely true. You use hashes for passwords because IT CANNOT BE REVERSED. If someone breaks into your production systems, they probably can get access to whatever encryption key you might use to encrypt passwords, and then they can easily get ahold of everyone's plain-text password. If passwords are hashed, there is no such vulnerability (though the hash may be broken if you don't use salt and your users choose dumb passwords).
When you have to reverse the transformation (Score:2)
Re: (Score:2)
* Some users like to be reminded of their password if they forget. If you lost your password, what kind of email would you rather get?
"Your password has been reset, and your new password is dFgk3b&4k72"
or,
"Your password is iloveyou123"
There are some websites I have accounts at which send that second "your password is XYZ123" type of e-mail.
Then again, my password on those types of sites is usually something like "password"
This isn't fair... (Score:4, Funny)
Re: (Score:2)
Double ROT13 was the best they could come up with? Haven't they heard about ROT26?
Re: (Score:2)
Actually, they used infinitely complex encryption by employing ROT13 infinitely many times (...for even values of infinity).
Re: (Score:2)
-200 rounds is even more secure.
Lucky me (Score:2)
My password "f00/.xyzzy/.b4r" is not even close to being like one of those on the list.
I know the founders/clowns (Score:5, Interesting)
I advised them prior to them leaving Iconix to start RockYou and shortly after they started angel round. I'm surprised they even got funding, I saw their code when they first got going -- hideously bad. It looked like little kids had created their sad PHP "infrastructure" and Flash slideshow app. They wanted help writing crontab tasks to run queries that took several minutes -- which I was able to pare down to under a second with proper query writing. Seems they had never heard of sub-selects or how to properly structure joins.
But, they clearly had connections within the entertainment industry and hit a chord with their target market of teenage girls and "bling" for their MySpace pages. And they got lots of money for a pretty easy concept.
Seeing them storing sensitive user data in plain text shows that not much has changed in their "core infrastructure".
In fact, they were doing it back then too and I told them that was bullshit -- too bad they chose not to listen.
Hopefully they've now learned how to use PHP's MCrypt Library, or at least use hashes.
But this security failure has been going on since 2005/2006
Re: (Score:2)
In fact, they were doing it back then too and I told them that was bullshit -- too bad they chose not to listen.
Still they made money, oodles of it would be left even after paying the 250K fine. And you are still posting in slashdot, "I told them so". As Scar told the mouse, "Life isn't fair".
Re: (Score:1)
I'm happy I didn't take a sys-admin position for them... I know of them and they know of me through the time they hosted with aplus.net... really, that should tell you something.
Sadly the fine is less than fixing it (Score:5, Informative)
$250,000 is basically one employee for one year (say 100k *2 for overhead/etc.) plus 50k in hardware/software. Properly securing this stuff is bound to cost more than the fines, so sadly I suspect many businesses simply do the math and decide to eat the fine.
I think Fight Club summed it up nicely:
Narrator: A new car built by my company leaves somewhere traveling at 60 mph. The rear differential locks up. The car crashes and burns with everyone trapped inside. Now, should we initiate a recall? Take the number of vehicles in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a recall, we don't do one.
Woman on plane: Are there a lot of these kinds of accidents?
Narrator: You wouldn't believe.
Woman on plane: Which car company do you work for?
Narrator: A major one.
Re: (Score:1)
I always thought the woman on the plane was the unreasonable one in that conversation...
Of course they're going to use that equation. Why wouldn't they? Why shouldn't they?
Re: (Score:2)
It fails to take into account people who don't settle immediately: court costs, damages if found guilty and public relations costs. It also fails to take into account the value of certainty vs. uncertainty in costs. And that's without all the more involved questions about whether a public recall costing X hurts the stock price more than secret payments of Y given current conditions, etc.
Well, reading "should" as a moral qu
Re: (Score:2)
On the other hand, taking all the vehicles off the road would also be disastrous...
The point is, at some point, you have to make a judgment of the benefit of having a thing (affordable cars, for instance) and the risk associated with having it. You have to put a value on human life, and it has to be normalized to the same units as the other factors for comparison.
If the car companies don't do this math, they would never make another car. There are just too many ways that people can be killed in an acciden
Re: (Score:2)
Obviously, there's some danger/value tradeoff societies have to make. I'm not claiming everything has to be perfect or not exist.
However, your claim that the recall must somehow involve junking all the cars is similarly extremist. Look at the Prius recall. A lot of other recalls are done in a rolling fashion, fixed in the dealership (so the recall may take a few weeks... that's another way of handling cost/danger tradeoffs) while the person reads a book for half an hour, and the defective part is replace
Re: (Score:2)
Of course they're going to use that equation. Why wouldn't they? Why shouldn't they?
They wouldn't if we would rise up with our fucking torches and pitchforks, like good citizens. If that were the case, they shouldn't. Otherwise, meh.
Re: (Score:3)
Right. Why in Gods name shouldn't they kill peopole if it makes them money? Killing people to make more money is just a good business decision and everyone who doesn't kill people for money is a stupid communist hippie nazi, right?
Re: (Score:2)
The fine is only one part of the settlement, and the fine is for violating the Children’s Online Privacy Protection Act.
The settlement also has them required to implement and maintain a data security program, submit to security audits for 20 years (probably 17 years longer than their remaining expected lifetime), etc. That is going to cost more than the fine most likely if they actually bother to implement it (if they don't I presume they get additional fines).
Favorite passwords (Score:1)
From TFA:
As a refresher, here were the top 10 passwords used by RockYou users:
123456, 12345, 123456789, Password, iloveyou, princess, rockyou, 1234567, 12345678, abc123,
So it hardly matters if the passwords are in plaintext or not.
" Rainbow tables? We don't need no stinking rainbow tables!"
Seems like a bizarre conclusion (Score:2)
Absent any specific regulation they're making up law on a case by case basis on the fly. In short they've created a new law but only for companies who get caught losing the information. If you're a company and you do exactly the same thing but nothing goes wrong you're excused from this law.
Re: (Score:2)
If you're a company and you do exactly the same thing but nothing goes wrong you're excused from this law.
So? Only people that actually cause damage are charged and punished. What's wrong with that?
Re: (Score:2)
It's not a contract, it's not a regulation, it's not a pre existing law, it's not a warranty and they didn't make a specific promise of what or how they would accomplish this. So what's happened effectively is that they've criminalized marketing hype. Well ok let's do that. Be careful what you wish for though.
Pre-existing law (Score:2)
it's not a pre existing law [...] So what's happened effectively is that they've criminalized marketing hype
I was under the impression that false advertising had been a crime at least as long as I've been alive.
Re: (Score:2)
Only if you definitively say something that's not true such as "This pill will cure cancer". If you say "We will protect you" the statement is sufficiently vague that a common sense and legal view of it is not that that vendor will under all circumstances keep you safe from all threats at all times.
Re: (Score:2)
Nulla poena sine lege. I wasn't arguing that. I was just nitpicking that the particular consequence you mentioned ("If you're a company and you do exactly the same thing but nothing goes wrong you're excused from this law.") is in fact not a bad thing at all.
Re: (Score:2)
Which is more or less logically consistent. It's also a good case for having no regulation at all and simply waiting for all the lawsuits after for instance, your food products kill people, etc. A real libertarian view of the world.
Common/best practices for personal data (Score:2)
Most applications I've worked with have stored passwords hashed and salted and stored credit card data offsite or not at all, but have kept other sorts of personal data (address, phone, etc.) in the database in plaintext.
I've always reasoned that encrypting the data is of little value, since the decryption keys would have to be on the server, and a server compromise would give the keys along with the data. This case is interesting though, since it seems only the database was compromised, so encrypted data
Re: (Score:2)
And every time you bounced a machine, you'd have to scramble to hand-key in a long, complex key that you weren't allowed by policy to even write down somewhere?
Bzzzt, thank you, please try again.
Re: (Score:2)
RAM of a running process is accessible to root via the debugger, so doesn't really provide better security than a file only root can read, although it may slow an attacker down a bit or foil a dim-witted attacker. As others have mentioned, there is also some systems management difficulty if services do not function until a password is entered into them.
At any rate, lots of interesting schemes are possible, but I was wondering if any of them were in wide use?
Thanks,
------Scott.
Hint: You need some salt in your game (Score:3)
Normal hashing is NOT enough to secure user passwords since anyone getting access will simply compare password fields to common hash values; e.g. MD5("12345"). Add another column to your password table containing a randomly generated string (the salt and it doesn't have to be that long). Then append or prepend that value to the user's password, hash, and store that hash value in the back end. Of course, you need to repeat the process to perform password validation and you will permanently "lose" the password, but your passwords are secure.
There are other algorithms you can pile on to obfuscate data as you see fit.
Doesn't everybody store passwords in plain text? (Score:1)
I wish all of them were fined $250K. We need a new "cyber-security" agency, with agents nosing password stores and issuing "cyber-tickets" for infractions.
What is the advantage of hashing? (Score:1)
I am yet to understand why it is better if the password is hashed. If the attacker gains access to the password database, then he can do anything with the server and the data of the users. He does not need the password of individual users at all.
Encryption of non-password data does not help anything, because the server must be able to decrypt those data. If the server is able to decrypt them, than the attacker on the server will also be able to decrypt them easily.
The attacker can only use the user pas
Re: (Score:2)
The advantage is that many people use the same password on multiple systems, so revealing a plaintext password to, say, Slashdot may also reveal your bank password. A hashed password can't be used to directly log into another account, though it can be cracked by a determined attacker if the password is simple. A salted and hashed password vastly increases the time required for an attacker to crack a hashed password, to the point where it is infeasible unless the password is very simple.
Of course everybody
Re: (Score:2)
Yes, thanks for the clarification, it only increases the time by preventing the use of rainbow tables (or, nowadays, simply googling the hash).
That'll teach em (Score:3)
I feel kind of bad for RockYou, massively over the top fines like that are just to send a message to other companies [/sarcasm]