Slashdot Mirror
FTC Fines RockYou $250,000 For Storing User Data In Plain Text
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."
"As a refresher, here were the top 10 passwords used by RockYou users: 123456 12345 123456789 Password iloveyou princess rockyou 1234567 12345678 abc123" Very original!
I am Jacks complete lack of Windows
We will
We will
Rock You!
We will
We will
Fine You!
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
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
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.
#fuckbeta #iamslashdot #dicemustdie
So why couldn't they get the same deal Sony got?
* 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?
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.
RockYou did the best they could by using double ROT13 encryption of these files. So sad to see them get fined.
My password "f00/.xyzzy/.b4r" is not even close to being like one of those on the list.
now we need to go OSS in diesel cars
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, lack of access controls, etc. They should be saying the design was defective, instead of saying the data format was.
#fuckbeta #iamslashdot #dicemustdie
And after the first fine of $250,000 for losing passwords stored in the clear that entire system is going to be re-evaluated.
I don't disagree with you on that. But I'm saying that the decision to build the system in that specific way (including the inclusion of the SQL injection vulnerability) is based upon the limitations of the people who made that decision.
Once you add the $250,000 fine and the chance of future fines I'm sure that they will re-visit that entire system and re-build it in such a way that passwords will be hashed.
Again, I'm not disagreeing with you. I'm saying that the decision to build the system in that way (lack of code auditing, lack of access controls, data format, etc) was based upon the limitations of the people making that decision back then ... and if they HAD known that they'd be slapped with a $250,000 fine for it they would have done it different.
And I'm sure that part of that different system would have been hashed passwords.
That's what civil suits are for. The FTC just enforces applies fines.
Dilbert RSS feed
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
... 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.
#fuckbeta #iamslashdot #dicemustdie
$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.
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.
So, when's Sony getting fined for storing data in the clear as exposed in the PSN and LulzSec breaches?
Give me Classic Slashdot or give me death!
A new bel-air for a new age?
Last time I forgot my password, their "lost password" page emailed it to me in plaintext...
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.
I think the Helix song will work better in this case...Gimme an F..I..N..E..whats ya got? FINE!, and what we gonna do? FINE YOU!
BTW you know you're old if you actually remember that song, sadly I saw the title and it instantly popped into my head. Hell I heard them playing AC/DC on the muzak channel at the local Walmart the other day, you know you're old when the "subversive' music you grew up on is now played for shoppers at the Wally World.
ACs don't waste your time replying, your posts are never seen by me.
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.
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 in the database with keys outside of the database would have provided some protection.
I can come up with lots of simple schemes for encrypting personal data in the database, but what I'm wondering is, how is this typically handled? Is it common to encrypt this sort of data? If so using what techniques for encryption and key management? Are there some well-known best practices that I haven't come across?
Thanks!
----Scott.
My Web Page
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.
I swear to God...I swear to God! That is NOT how you treat your human!
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 password for one purpose: he can use it to enter other accounts of the user. But only if the user has the same password everywhere. In which case the user has already given up any security. That is the same as having a password of 123456. If the attacker is on the server he can eavesdrop on the communication and slowly retrieve the passwords of all users anyway, regardless of hashing, within a few days.
2.5 cents per user credential lost.
I feel kind of bad for RockYou, massively over the top fines like that are just to send a message to other companies [/sarcasm]
These comments are my personal opinions and do not necessarily reflect the opinions of the other voices in my head.
No, in that case simply encrypt the data instead of hashing it. Storing passwords in clear text in a database is always stupid.
Consider how the eBay API handles applications: Each application developer signs an agreement with eBay, and eBay provides a shared secret that identifies that application. The application directs the eBay user to a page on eBay.com that asks for the user's name and password, and then eBay returns a session cookie to that application. This cookie identifies the user and is valid only for that application. Then the problem becomes how to protect the application's shared secret from people who have physical access to the server or to the end-user devices running the application.
When retrieving resources from a third party on the user's behalf, they need to display the user's password to the third party if it hasn't fully implemented OAuth or something analogous. Twitter and Amazon support OAuth, but several other services do not.
But you need to be able to reverse the transformation if you have to provide this password when interacting with a third party on the user's behalf. One such password is a taxpayer ID used for communication with national revenue authorities.
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.
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.
God, no!
Free Martian Whores!
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!
Just because it CAN be done, doesn't mean it should!
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.
#fuckbeta #iamslashdot #dicemustdie
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 encrypted value.
What's the encryption key? It's based off of your password on MY system (which IS hashed and salted). So I never need to store it.
You login on MY system and your gmail password gets decrypted and sent to gmail to log you in over there.