Forgot your password?
typodupeerror
Security The Almighty Buck Your Rights Online

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

Posted by samzenpus
from the pay-up dept.
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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • Passwords!? (Score:5, Interesting)

    by smc170 (2609895) on Tuesday April 03, 2012 @06:32PM (#39566281) Homepage Journal
    "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!
    • by Yvan256 (722131)

      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)

    by maroberts (15852) on Tuesday April 03, 2012 @06:34PM (#39566313) Homepage Journal

    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)

    by girlintraining (1395911) on Tuesday April 03, 2012 @06:45PM (#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.

    • 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

      • 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,

        • by khasim (1285)

          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 designe

          • by girlintraining (1395911) on Tuesday April 03, 2012 @07:41PM (#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.

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

              • 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?

                • by Kalriath (849904)

                  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.

                  • by rjstanford (69735)

                    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.

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

                  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.

                  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?

                  Simple, encrypt it and store the enc

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

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

        • by dave420 (699308)
          No, in that case simply encrypt the data instead of hashing it. Storing passwords in clear text in a database is always stupid.
          • 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.

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

      Personal user information? SS Numbers, addresses? Really?

      • by heypete (60671)

        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.

    • 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

      • by isilrion (814117)

        [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

    • by sootman (158191)

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

      • by Anonymous Coward

        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

        • Since when do normal systems need to display your password to you?
        • by sootman (158191)

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

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

      • by tepples (727027)
        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?
        • by praxis (19962)

          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.

          • by tepples (727027)

            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?

            • by praxis (19962)

              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.

              • by tepples (727027)

                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.

                • by praxis (19962)

                  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.

  • Hmmm (Score:3, Insightful)

    by AmberBlackCat (829689) on Tuesday April 03, 2012 @06:47PM (#39566449)
    So why couldn't they get the same deal Sony got?
  • by Spy Handler (822350) on Tuesday April 03, 2012 @06:47PM (#39566455) Homepage Journal

    * 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?

    • by truedfx (802492) on Tuesday April 03, 2012 @06:53PM (#39566521)
      What's most wrong with that is the suggestion that one might use phpmyadmin for fun.
    • by Skapare (16644)

      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.

    • by Rasperin (1034758)
      Could use encryption/decryption instead of a hash (and you can still just compare the encrypted values, a two for one special!)
      • The reason people use hashes is because they are fast. Encryption/Decryption is relatively slow.
        • by Anonymous Coward

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

          • 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.
    • by TubeSteak (669689)

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

  • by Metricmouse (2532810) on Tuesday April 03, 2012 @07:00PM (#39566583)
    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.

  • by l0ungeb0y (442022) on Tuesday April 03, 2012 @07:33PM (#39566869) Homepage Journal

    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

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

    • by druiid (109068)

      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.

  • by seifried (12921) on Tuesday April 03, 2012 @07:46PM (#39566987) Homepage

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

    • 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?

      • 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 qu

        • 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

          • 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

      • by drinkypoo (153816)

        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.

      • by oreaq (817314)

        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?

    • by Darinbob (1142669)

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

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

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

    • by oreaq (817314)

      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?

      • by gelfling (6534)

        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.

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

          • by gelfling (6534)

            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.

        • by oreaq (817314)

          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.

          • by gelfling (6534)

            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.

  • 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

  • by GodfatherofSoul (174979) on Wednesday April 04, 2012 @01:04AM (#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.

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

    • by sgifford (9982)

      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

  • by Captain Hook (923766) on Wednesday April 04, 2012 @04:30AM (#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]

This login session: $13.76, but for you $11.88.

Working...