×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

FTC Fines RockYou $250,000 For Storing User Data In Plain Text

samzenpus posted about 2 years ago | from the pay-up dept.

Security 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

127 comments

They fined RockYou like a hurricane! (0, Funny)

Anonymous Coward | about 2 years ago | (#39566273)

A category 3. Could have been worse.

Re:They fined RockYou like a hurricane! (2, Funny)

mcl630 (1839996) | about 2 years ago | (#39566287)

We will
We will
Rock You!

We will
We will
Fine You!

Re:They fined RockYou like a hurricane! (-1, Offtopic)

RealDealMcneal (2609921) | about 2 years ago | (#39566389)

Well, to begin, I'm just your average guy. But unlike your average guy, I once had everything anyone could ever want: a gorgeous wife, a beautiful two-story house, an adorable seven year old daughter, a stable job, and a nice salary. Basically, I was living the American dream. None of my needs or wants were left unfulfilled. The family always got along, and everything was perfect.

Until one day, that is. Following one of my routine doctor appointments, my doctor informed me that I had lung cancer and that I only had a few years to live at most. As you can imagine, I was shocked. Not just shocked; I could see all of my hopes and dreams being shattered right before my very eyes. Still, my doctor gave me hope by telling me that there was a chance, however slim, that Chemotherapy and various other things could help me. After speaking with my wife, I decided to receive the treatments.

All was not lost. I still had a perfect family that I could rely on and get emotional support from. I still had hope for the future. I'm a firm believer that you should make the best of things rather than wallow in depression. I had to press on: not just for my sake, but for the sake of my loved ones. But my strong resolve was soon shattered.

The family I thought I could count on betrayed me. My wife, whom I loved deeply, filed for a divorce. She said that she could not handle the emotional trauma of being with someone who had cancer. She apologized profusely, but no matter what I said, I could not change her mind. I screamed, I cried, and I begged her to rethink her decision, but it was all to no avail.

In my madness, I made all kinds of accusations. I said that she was cheating on me, that she never loved me, that she just married me for my money, and various other things. I soon learned, however, that a few of those were more than just baseless accusations. I began stalking her, going through all of her personal possessions, and trying uncover any secrets she may have been keeping. What I discovered horrified me: she had been cheating on me with another man for the past year. She must have been waiting for an opportune time to abandon me for this other man.

When confronted about her betrayal, she screamed at me, told me it was none of my business, told me that I was always a worthless husband, and told me that I was an abusive man. I soon discovered that there was absolutely nothing that I could do. My marriage was in shambles, and by this point, I was on the brink of suicide. The only thing keeping me going was my devotion to my precious daughter.

It wasn't long before I received news from my insurance company that they were getting rid of my coverage. They gave me multitudes of vague and bogus reasons, but anyone could figure out their true reason: they did not want to waste money on a dying man. Naturally, I planned to fight this with every fiber of my being, but I knew it would be a long, drawn out process.

In the span of a year, I went from a very happy man who had everything he wanted to a miserable shell of what I once was. I couldn't take it anymore. Despite the fact that I wanted to remain in this world for the sake of my daughter, I tried committing suicide four times. All four attempts failed. I needed something to take my misery, regret, and anger out on. First I began verbally abusing my daughter. It wasn't long before I began physically abusing her. Sometimes I did it with my bare hands, and other times I used various objects. Beating my daughter soon became my only pleasure. My life had spiraled out of control into a den of anguish, uncertainty, and madness.

That's when it happened: I found MyCleanPC [mycleanpc.com]. I downloaded it, scanned my computer, and had it fix all of my problems. MyCleanPC [mycleanpc.com] is outstanding! My computer is running faster than ever!

My wife's response? “MyCleanPC [mycleanpc.com] came through with flying colours where no one else could!”

My daughter was absolutely overjoyed. As soon as she heard and saw just how effective MyCleanPC [mycleanpc.com] was, she told everyone, “MyCleanPC [mycleanpc.com] totally cleaned up my dad's system and increased his speed!”

If you're having computer troubles, I highly recommend you download MyCleanPC [mycleanpc.com] and run a free scan. It's a high-quality piece of software that will solve all of your problems. MyCleanPC [mycleanpc.com] completely saved my life! Wow! Thanks MyCleanPC [mycleanpc.com]! I love you MyCleanPC [mycleanpc.com]!

MyCleanPC: For a Cleaner, Safer PC. [mycleanpc.com]

Re:They fined RockYou like a hurricane! (0)

Anonymous Coward | about 2 years ago | (#39567673)

+1 funny if i had mod points today...

Re:They fined RockYou like a hurricane! (1)

hairyfeet (841228) | about 2 years ago | (#39567717)

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.

Re:They fined RockYou like a hurricane! (0)

Anonymous Coward | about 2 years ago | (#39568927)

We will
We will
Pay the ridiculously tiny fine and keep rocking You!

(The apocryphal verses)

Re:They fined RockYou like a hurricane! (1)

Hatta (162192) | about 2 years ago | (#39567201)

So, when's Sony getting fined for storing data in the clear as exposed in the PSN and LulzSec breaches?

Re:They fined RockYou like a hurricane! (2)

Mad Leper (670146) | about 2 years ago | (#39567727)

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!? (5, Interesting)

smc170 (2609895) | about 2 years ago | (#39566281)

"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!

Re:Passwords!? (-1)

Anonymous Coward | about 2 years ago | (#39566471)

If only RockYou didn't have an affirmative action hiring policy they could have gotten the more qualified white candidate who wouldn't have stored it plaintext.

What? (1)

Yvan256 (722131) | about 2 years ago | (#39566559)

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 (5, Informative)

maroberts (15852) | about 2 years ago | (#39566313)

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 (5, Informative)

girlintraining (1395911) | about 2 years ago | (#39566431)

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. So storing something in plaintext, or not, is not something worth suing and fining someone over. That said, storing the passwords in the clear is almost always a bad idea; and in this day and age, everyone should be using password hashes, preferably with a salt as well, as rainbow tables are increasingly common and accessible as storage costs decrease.

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.

Re:Seems silly (1)

smc170 (2609895) | about 2 years ago | (#39566469)

If in the terms and conditions they were to say: "We will store your data as plain text" or something like that, could they still get fined? If the user agreed then that's their fault, not the companies?

Layers of problems. (0)

khasim (1285) | about 2 years ago | (#39566585)

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 over again.

If 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.

Re:Layers of problems. (2)

girlintraining (1395911) | about 2 years ago | (#39566645)

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.

Re:Layers of problems. (1)

khasim (1285) | about 2 years ago | (#39566801)

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.

And after the first fine of $250,000 for losing passwords stored in the clear that entire system is going to be re-evaluated.

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.

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.

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.

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.

Re:Layers of problems. (5, Informative)

girlintraining (1395911) | about 2 years ago | (#39566951)

... 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. (1)

khasim (1285) | about 2 years ago | (#39567091)

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:Let me try a different way. (0)

Anonymous Coward | about 2 years ago | (#39567385)

> (impersonating you via login credentials to a third party) AND have that system use only hashed passwords
Wat? How would that work? Genuinely curious.

Re:Let me try a different way. (1)

The Dancing Panda (1321121) | about 2 years ago | (#39567849)

You do it via lookup: Log in with your own credentials, then if you have rights, look up a user you'd like to impersonate. This way you don't need their password at all, only your own.

Re:Let me try a different way. (0)

Anonymous Coward | about 2 years ago | (#39568341)

How does that help you gain access, to, say, your Slashdot account through Google? You login with your Google account to google, they store your hashed Slashdot password, and...somehow use that to log you in and post?

How eBay handles applications (1)

tepples (727027) | about 2 years ago | (#39571115)

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.

Re:Let me try a different way. (1)

isilrion (814117) | about 2 years ago | (#39571411)

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 username/password to that someone, and that password cannot be hashed (because otherwise he wouldn't be able to retrieve it to authenticate to the service).

Re:Let me try a different way. (0)

Anonymous Coward | about 2 years ago | (#39568263)

Well then, please describe how you would build a system that can aggregate email from multiple 3rd party POP3 email accounts using only hashed passwords. Oh, you don't get to dictate what authentication protocols the 3rd party accounts use; it's just plaintext username/passwords as per the original POP3 RFCs.

Sometimes plaintext passwords are unavoidable. You can encrypt the fields and decrypt as needed, but that can be defeated if the attacker can download the program itself in additional to the encrypted data. You're not really making it significantly more secure, you're just moving the problem somewhere else.

Re:Let me try a different way. (1)

girlintraining (1395911) | about 2 years ago | (#39568419)

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:Let me try a different way. (1)

Kalriath (849904) | about 2 years ago | (#39568533)

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:Let me try a different way. (1)

rjstanford (69735) | about 2 years ago | (#39569825)

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.

Re:Let me try a different way. (0)

Anonymous Coward | about 2 years ago | (#39569791)

You missed one point - the credentials are for a site you don't control.

Re:Layers of problems. (1)

dave420 (699308) | about 2 years ago | (#39569573)

No, in that case simply encrypt the data instead of hashing it. Storing passwords in clear text in a database is always stupid.

Encrypt with what key? (1)

tepples (727027) | about 2 years ago | (#39571253)

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:Seems silly (0)

Anonymous Coward | about 2 years ago | (#39566805)

All they need is login credentials that should be hashed. If they want to store data store it on the users PC in a fashion where they can get to it if the user provides their login credentials.

Re:Seems silly (1)

mlts (1038732) | about 2 years ago | (#39567071)

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:Seems silly (1)

interval1066 (668936) | about 2 years ago | (#39566947)

There are perfectly legitimate reasons to maintain user account information in the clear

Personal user information? SS Numbers, addresses? Really?

Re:Seems silly (1)

heypete (60671) | about 2 years ago | (#39569461)

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:Seems silly (1)

Beeftopia (1846720) | about 2 years ago | (#39567577)

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 programming interfaces to use them are very simple. A developer should take 60 minutes to learn about them, first out of respect for the users, and second, to avoid ending up in the news.

Re:Seems silly (0)

Anonymous Coward | about 2 years ago | (#39569015)

The biggest problem with two way encryption is that, if they've already penetrated the server to get the data, they can probably poke around enough to get the decryption password. Which is probably stored in plaintext somewhere, what with having to be able to access it...

Re:Seems silly (1)

dave420 (699308) | about 2 years ago | (#39569577)

But that wouldn't happen with an SQL injection vulnerability - they've not penetrated the actual server's filesystem, just the database.

Re:Seems silly (1)

sootman (158191) | about 2 years ago | (#39567579)

> 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:Seems silly (1)

Anonymous Coward | about 2 years ago | (#39568207)

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 machine to capture decryption keys too.

Re:Seems silly (1)

hawkinspeter (831501) | about 2 years ago | (#39569295)

Since when do normal systems need to display your password to you?

For sites not supporting OAuth (1)

tepples (727027) | about 2 years ago | (#39571171)

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.

Re:Seems silly (1)

sootman (158191) | about 2 years ago | (#39571095)

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:Seems silly (1)

chris.alex.thomas (1718644) | about 2 years ago | (#39569685)

under what conditions would you consider storing a password as clear text not a bad idea?

Re:Seems silly (1)

tepples (727027) | about 2 years ago | (#39571179)

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?

Who is the victim here? (0)

fizzer06 (1500649) | about 2 years ago | (#39566435)

"In agreeing to FTCâ(TM)s settlement, RockYou has been barred from future deceptive claims regarding privacy and data security, has to implement and maintain a data security program, must submit to security audits by independent third-party auditors every other year for 20 years, is barred from future violations of the COPPA Rule, is required to delete information collected from children under age 13, and must pay a $250,000 civil penalty."

It's nice the government made a few bucks on this. I didn't see where the real victims, the kids, got a dime.

Reasons to store in plaintext (4, Funny)

Spy Handler (822350) | about 2 years ago | (#39566455)

* 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 (4, Funny)

truedfx (802492) | about 2 years ago | (#39566521)

What's most wrong with that is the suggestion that one might use phpmyadmin for fun.

Re:Reasons to store in plaintext (0)

Anonymous Coward | about 2 years ago | (#39566621)

If you're going to hash the passwords, you should salt it too,...

My doctor told me to cut down on salt - so no salting on my hash. Just lots of ketchup.

Re:Reasons to store in plaintext (0)

Anonymous Coward | about 2 years ago | (#39567177)

I know you were trying to be funny, but check the sodium content in your ketchup. And mustard too while you're at it.

Re:Reasons to store in plaintext (1)

Skapare (16644) | about 2 years ago | (#39566641)

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:Reasons to store in plaintext (1)

Rasperin (1034758) | about 2 years ago | (#39566643)

Could use encryption/decryption instead of a hash (and you can still just compare the encrypted values, a two for one special!)

Re:Reasons to store in plaintext (1)

The Dancing Panda (1321121) | about 2 years ago | (#39567863)

The reason people use hashes is because they are fast. Encryption/Decryption is relatively slow.

Re:Reasons to store in plaintext (1)

Anonymous Coward | about 2 years ago | (#39568381)

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 (1)

tepples (727027) | about 2 years ago | (#39571213)

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.

Re:Reasons to store in plaintext (1)

TubeSteak (669689) | about 2 years ago | (#39568163)

* 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... (4, Funny)

Metricmouse (2532810) | about 2 years ago | (#39566583)

RockYou did the best they could by using double ROT13 encryption of these files. So sad to see them get fined.

Re:This isn't fair... (0)

Anonymous Coward | about 2 years ago | (#39566901)

Double ROT13 was cracked ages ago. You need to use 200 rounds of ROT13 at least to be secure.

Re:This isn't fair... (1)

FrootLoops (1817694) | about 2 years ago | (#39569141)

Actually, they used infinitely complex encryption by employing ROT13 infinitely many times (...for even values of infinity).

I know the founders/clowns (5, Interesting)

l0ungeb0y (442022) | about 2 years ago | (#39566869)

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:I know the founders/clowns (0)

Anonymous Coward | about 2 years ago | (#39567225)

We keep moving into their old buildings. I was actually unsure what they did until this article (thought they were related to the company that used to be in the complex that did radio/music promotions). I really don't see that many of them walking around anymore but they do seem to be on the young side.

This just sounds like another rerun from the dot-com days. Someone has an idea and thinks that is all that is needed to be a high tech innovator.

Re:I know the founders/clowns (1)

140Mandak262Jamuna (970587) | about 2 years ago | (#39568053)

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".

Sadly the fine is less than fixing it (4, Informative)

seifried (12921) | about 2 years ago | (#39566987)

$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:Sadly the fine is less than fixing it (0)

zippthorne (748122) | about 2 years ago | (#39567255)

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:Sadly the fine is less than fixing it (0)

Anonymous Coward | about 2 years ago | (#39567323)

And besides, it is not normal for there to be people whose only job is to do that kind of calculation. Deciding on the best use of company resources - which path has the largest expected profit over probable scenarios - is an important part of the job of every manager out there. Most of them do it by the seat of their pants, but the more important the decision, the more often the manager must justify the decision in terms of actual estimated costs and probabilities. They teach that kind of stuff at MBA courses.

Re:Sadly the fine is less than fixing it (0)

Anonymous Coward | about 2 years ago | (#39568701)

Which MBA school did you go to?

Re:Sadly the fine is less than fixing it (0)

Anonymous Coward | about 2 years ago | (#39570021)

Which MBA school did you go to?

A major one.

Re:Sadly the fine is less than fixing it (1)

Actually, I do RTFA (1058596) | about 2 years ago | (#39568467)

Of course they're going to use that equation. Why wouldn't they?

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.

Why shouldn't they?

Well, reading "should" as a moral question, I doubt that the aggregate out-of-court settlements really capture the full cost of leaving the vehicles on the road.

Re:Sadly the fine is less than fixing it (1)

drinkypoo (153816) | about 2 years ago | (#39569873)

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:Sadly the fine is less than fixing it (2)

oreaq (817314) | about 2 years ago | (#39569975)

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:Sadly the fine is less than fixing it (1)

Darinbob (1142669) | about 2 years ago | (#39567265)

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).

equal protection (0)

Anonymous Coward | about 2 years ago | (#39567065)

Ok. So what about Sony 's fine. Or the veterans administration, who not only compromised such info, but has done so repeatedly? Frankly, rockyou didn't have critical info/services and is not REQUIRED BY LAW to provide greater protection than they did. The govt IS required by law to protect that VA info.

Favorite passwords (0)

godel_56 (1287256) | about 2 years ago | (#39567205)

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 (1)

gelfling (6534) | about 2 years ago | (#39567461)

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:Seems like a bizarre conclusion (1)

oreaq (817314) | about 2 years ago | (#39569991)

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:Seems like a bizarre conclusion (1)

gelfling (6534) | about 2 years ago | (#39570223)

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 (1)

tepples (727027) | about 2 years ago | (#39571275)

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.

If only they'd used ROT13... (0)

Anonymous Coward | about 2 years ago | (#39567657)

They'd have avoided this fine.

Common/best practices for personal data (1)

sgifford (9982) | about 2 years ago | (#39568455)

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.

Re:Common/best practices for personal data (0)

Anonymous Coward | about 2 years ago | (#39569391)

Couldn't you write a system that holds the decryption key in ram only? Have the program require you to enter it as part of the startup, and never write it to disk.

Re:Common/best practices for personal data (1)

rjstanford (69735) | about 2 years ago | (#39569837)

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:Common/best practices for personal data (0)

Anonymous Coward | about 2 years ago | (#39569985)

Who said you can't write it down? You could even put it on a sticky note on the monitor. The point is that you can't read it by hacking into an internet facing machine.

Re:Common/best practices for personal data (1)

sgifford (9982) | about 2 years ago | (#39570309)

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 (2)

GodfatherofSoul (174979) | about 2 years ago | (#39568753)

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? (0)

Shompol (1690084) | about 2 years ago | (#39568757)

I have lost count of the number of times when I recover a forgotten password and the website emails my exact password "reminder". At one point I was "reminded" by a rep over the phone. And even these are a small percentage of total, because not revealing my password to me does not guarantee that it is not stored in plain text anyway.

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.

How to report to FTC? (0)

Anonymous Coward | about 2 years ago | (#39568759)

How would I go about reporting to the FTC about a website storing passwords in the clear? or do they only care if the passwords are leaked? There is a forum I use regarding a medical practice management system which emails users their username and password in the clear when you sign up and I've been trying to tell them to store a hash instead of the cleartext password for about 3 years now...

What is the advantage of hashing? (1)

dshk (838175) | about 2 years ago | (#39569185)

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.

Re:What is the advantage of hashing? (1)

sgifford (9982) | about 2 years ago | (#39570371)

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 knows (or should know) that using the same password for Slashdot and your bank is a bad idea (you could have a bank support rep using up your precious karma!), but it is still very common, and it's irresponsible for a developer to expose their users' passwords if they have made this common mistake.

That'll teach em (2)

Captain Hook (923766) | about 2 years ago | (#39569435)

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]

Then pay us like lawyers.. (0)

Anonymous Coward | about 2 years ago | (#39570055)

I have always thought coders should be paid like lawyers.. when we start becoming accountable for peoples privacy we should get paid for being *responsible*.
As long as they keep paying peanuts everyone is just going to get monkeys.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...