FTC fines RockYou $250,000 for storing user data in plain text

FTC fines RockYou $250,000 for storing user data in plain text

Summary: The Federal Trade Commission has fined social game developer RockYou $250,000 for storing 32 million e-mail addresses and passwords, including 179,000 belonging to minors, in plain text.

SHARE:

Do you remember the RockYou fiasco? You probably don't as it happened in late 2009. Let me refresh your memory: 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 (FTC).

The FTC charged that, while touting its security features, RockYou failed to protect the privacy of its users, allowing hackers to access the personal information of 32 million users. The FTC also alleged in its complaint that RockYou violated the Children's Online Privacy Protection Act (COPPA) Rule in collecting information from approximately 179,000 children.

In agreeing to FTC'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. You can read the full 12-page complaint from the FTC here: PDF.

The FTC's COPPA Rule requires that website operators notify parents and obtain their consent before they collect, use, or disclose personal information from children under 13. The Rule also requires that website operators post a clear, understandable, and complete privacy policy. The FTC alleged that RockYou knowingly collected children's email addresses and associated passwords during registration – without their parents' consent – and asked for kids' date of birth, meaning it accepted registrations from kids under 13. The FTC charged that RockYou violated the COPPA Rule by:

  • Not spelling out its collection, use and disclosure policy for children's information.
  • Not obtaining verifiable parental consent before collecting children's personal information.
  • Not maintaining reasonable procedures, such as encryption to protect the confidentiality, security, and integrity of personal information collected from children.

RockYou operated a website that allowed consumers to play games and use other applications, including one that let you create slide shows from your photos, add your own captions and music supplied by the site. To save your slide shows, you had to enter your e-mail address and password.

As a refresher, here were the top 10 passwords used by RockYou users:

  1. 123456
  2. 12345
  3. 123456789
  4. Password
  5. iloveyou
  6. princess
  7. rockyou
  8. 1234567
  9. 12345678
  10. abc123

If any of these resembles your password, please go change it. If you are still storing your customer data in plain text, please go encrypt it.

See also:

Topics: Software Development, Browser, Security

Emil Protalinski

About Emil Protalinski

Emil is a freelance journalist writing for CNET and ZDNet. Over the years,
he has covered the tech industry for multiple publications, including Ars
Technica, Neowin, and TechSpot.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

5 comments
Log in or register to join the discussion
  • TMobile should be next...

    I don't know what TMobile's problem is, but it seems once per year they SMS me my password in clear text for their website! With a reminder that I can login to their website.

    FTC should go after them and they should be required to notify everyone when its fixed. [b]Don't store passwords in anything less then SHA1 hash![/b]
    x21x
    • SHA1 shouldn't be used

      SHA1 has issues and shouldn't be used (MD5 shouldn't be used either). You shouldn't be using anything less than SHA256.
      Bonesnap
      • Or...

        You could just say SHA512 should be the min until SHA-3 is finalized. Since GPU + Cloud cracking is increasing the speed at which brute force can be done.

        As the hash function increases though your actual password length should also increase using long [i]long[/i] sentences.
        x21x
  • Yikes!!!

    Plain text? Yikes!!!

    At the very least, hash them. At the very, [b]very[/b] least.

    "If you are still storing your customer data in plain text, please go encrypt it."

    Yes, please! Use strong hashes for passwords and well tested cryptographic methods to store user data. If you're providing a public service that's available online, you should never, [i]ever[/i] be using a text file.

    EDIT: Don't even do it [i]temporarily[/i], as an initial reading of the PDF indicated they did. Encrypt it ASAP. Indeed, you may want to encrypt it via JavaScript before it even leaves the browser. It should stay encrypted as long as possible. And of course, use HTTPS as well to make sure the entire connection is secure. But don't rely solely on HTTPS - that just secures the connection itself, it doesn't secure the data outside of the connection.
    CobraA1
  • Careful!

    Let's be very careful about how we bandy the word "encryption" about. While hashing the passwords would have absolutely provided some level of protection (depending on the hash used), encrypting the customer info would not have helped much against this threat. Why not? Because the attacker used SQL injection via the web application to access the backend data and before an application can present data to the user, its database has to...you guessed it, unencrypt it! Implementing security controls can be very expensive. It's important to implement the ones that protect against the highest risk. The most obvious vulnerability here was the lack of input validation in the app that permitted the SQL injection to occur, not encryption. Yet I see no discussion of that in the article.
    bluezoo7@...