SQL failure exposes plain text passwords

happygeek 1 866 Views

File under FAIL: social network widget maker RockYou has fallen victim to a SQL injection flaw and as a result some 32.6 million users are being urged to change their passwords as a matter of urgency.

Security specialists Imperva discovered the problem at social networking development site and issued a warning to users of its applications earlier this week. " is not just any software site. Since its creation in 2006, it's become the hub for many social networking sites such as Bebo, Facebook and Myspace, to mention but a few" said Amichai Shulman, Imperva CTO.

Shulman claimed that the "vast majority" of user names and passwords were, by default, the same as the users webmail accounts, adding "the users are young and security is not top of mind, but nonetheless companies need to keep them protected and ensure their details are safe... it is the responsibility of application owners to protect the information trusted to them by users".

TechCrunch reports that the hacker exploit took advantage of a "trivial SQL injection vulnerability" which "has been well documented for over a decade" and is "extremely basic in execution, yet catastrophic in impact". Worse yet, it points out that RockYou only requires 5 character passwords, and that these were stored in plain text. If this were not bad enough, users of RockYou widgets were prompted to "enter their third-party site credentials directly into the RockYou site when sharing data or an application". Indeed, SQL injection exploits are nothing new and have hit the most unlikely of people including security experts Kaspersky. That said, I agree with TechCrunch that this really does look like it was a security disaster just waiting to happen. Not least thanks to a basic misunderstanding of the importance of a .

RockYou, meanwhile, have made the following security :

Our users' privacy and data security have always been a priority for RockYou and we strive to keep them secure. Our users have confidence in our services and we will continue to ensure that confidence is deserved.

As we previously explained, one or more individuals illegally breached one of our databases that contained the usernames and passwords for about 32 million users in an unencrypted format. It also included these users' email addresses. This database had been kept on a legacy platform dedicated exclusively to RockYou.com widgets. After learning of the breach, we immediately shut the platform down to prevent further breaches.

Importantly, RockYou does not collect user financial information associated with RockYou.com widgets. In addition, user information for users of RockYou applications on partner sites, including Facebook, MySpace, Hi5, Friendster, Bebo, Orkut, Mixi, Cyworld, etc., were not implicated by the breach. The platform breach also did not impact any advertiser or publisher information, which we maintain on a separate and secure system that is not a legacy platform. Lastly, the security breach did not affect our advertising platform or our social network applications.

However, because the platform breached contained user email addresses and passwords, we recommend that our RockYou.com users change their passwords for their email and other online accounts if they use the same email accounts and passwords for multiple online services. Changing passwords may prevent anyone from gaining unauthorized access to our users' other online accounts. We are separately communicating with our users so that they take this step and are informed of the facts.

We are investigating the data breach, reviewing our security protocols, and implementing new practices to prevent this from happening again. For example, we are taking the following steps:

1. We are encrypting all passwords;
2. We are upgrading the legacy platform with the same infrastructure and industry standard security protocols we employ on our partner applications platforms;
3. We are reviewing our current data security features and ensuring that they meet industry standards and best practices; and
4. We are cooperating with Federal authorities to investigate the illegal breach of our database.

We are sorry for the inconvenience this illegal intrusion onto the RockYou system has caused our users. We will continue to advise our users of any information that would help them.

Dani AI

Generated

A concise expert summary and practical checklist tied to the points raised by , and .

This incident is the classic two‑failure pattern: an injectable query in the application layer plus storage of account verifiers in a reversible form. That combination turns a “trivial” input flaw into a catastrophic data leak — SQL injection gives access to whatever the database contains, so protecting both the query surface and stored verifiers is essential. (cheatsheetseries.owasp.org)

For : canonical, actionable documentation on the vulnerability class is the OWASP SQL Injection and Query Parameterization cheat sheets. They explain why string‑concatenated queries are dangerous and show the safer alternatives (prepared/parameterized queries, ORMs, query parameterization). Start there when hunting or fixing SQLi issues. (cheatsheetseries.owasp.org)

To : when services ask for selected characters of a password (the “enter 2nd and 9th character” pattern) it often signals a non‑standard server-side design that can be hard to do securely; implementations and attacks on partial‑password schemes are discussed in academic analyses. As a rule, do not rely on partial prompts as a substitute for proper one‑way storage and modern authentication controls. For password verifiers, follow modern password‑storage guidance (per‑user salt and a memory‑hard hash such as Argon2id — avoid reversible storage or plain text). (arxiv.org)

Immediate, practical checklist:

  • Fix inputs: convert vulnerable queries to parameterized/prepared statements and add allow‑list validation.
  • Reduce blast radius: run the DB under least privilege and isolate legacy platforms.
  • Replace verifiers: migrate to salted, memory‑hard hashing (Argon2id/bcrypt/scrypt) and require resets if exposure is confirmed.
  • Stop collecting third‑party credentials: adopt delegated auth (OAuth/OpenID Connect) for integrations.
  • Improve detection: add logging, WAFs, and regular SAST/DAST security testing.
  • User mitigation: force a reset, invalidate sessions/tokens, and push MFA. (cheatsheetseries.owasp.org)

These steps address both sides of the failure — eliminate injection paths, and make stored credentials useless to an attacker.

Member Avatar for RobertSchifreen
RobertSchifreen 0 Newbie Poster

Amazing how many companies clearly don't encrypt their password database. Just look, for example, at banks which ask for the 2nd and 9th character of your password when you log in. The only way they could do this is if their copy isn't encrypted.

Member Avatar for Alex_
Alex_ 0 Junior Poster

Where can i find this "trivial SQL injection vulnerability" documented? I want to read about it.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview