back to article Formspring springs a leak: 28 MILLION passwords reset after raid

Formspring has told its 28 million users to change their passwords following the discovery of a security breach. A sample of 420,000 password hashes for the question-and-answer website have been posted online, sparking concerns that the entire user base might have been exposed. In response, Formspring disabled users' passwords …


This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward


    I only signed up briefly, discovered how crap Formspring was, nothing like what was promoted, asked for my account to be deleted. Seems they never bothered...

  2. ukgnome

    Development and live should never be connected

    1. Anonymous Coward
      Anonymous Coward


      ...but it's so convenient!!! And so much fun, knowing one wrong move will cause chaos! Adrenaline is good.

    2. Lord Voldemortgage

      "Development and live should never be connected"

      Reading between the lines it looks like they might have dumped a copy of the live database onto a development server - I've seen it done.

      1. Anonymous Coward
        Anonymous Coward

        I don't know, it sounds like they might have had a development server with web access that used the production DB server

        Terrible security managment.

      2. Tom 13

        @Lord Voldemortgage

        In a completely proper environment, development should NEVER be externally accessible. Development is on an internal network, best isolated from the work network as well as testing and production. When development is done it gets moved to the test server, which is fully identical to and has the same security requirements as the production server. Final testing is done and then the tested platform is moved to the production server (or test server is promoted to prod and prod demoted to test depending on internal practices).

        In that environment, it may be acceptable to use a copy of the live database for development, pursuant to other requirements like protecting personal info. I can see the use for a copy of the live database, (nothing is ever foolproof because fools are so ingenious OR your typical developer would never think of doing something that stupid with the configuration of their testing data), but it certainly entails risk and proper precautions need to be taken.

    3. Anonymous Coward
      Anonymous Coward

      One of my all time favourite examples of the pitfalls in blurring the lines between live and dev/test environments.

      A new system was built and went into test. During testing, data was ported from the shonky old system and enhanced with other data from a variety of sources, including a shedload of manual entry and correction, as much of what was done previously was manual work using paper records. Much testing was then performed, culminating in effectively live running for some two months and all was deemed well. The end result was a test server that had everything required in production, so a few corners were cut and that server went into production.

      Then the project was closed. As part of the closure process, the IT lads decommissioned the machine they had on their books as the test server assigned to the project......Oops. Now what's the other big difference between test and production? Ah yes, that'll be the fact that production servers are backed up regularly.........Double Oops......

    4. Tom 13

      Re: Development and live should never be connected

      You forgot the WTF?!?!?!?!!! title.

      I are only helpdesk and even I knowed that.

  3. Gordan

    Upgrading from salted SHA256?

    Really? That sounds pretty paranoid. Those hashes are only going to be voulnerable to dictionary attacks on any weak passwords that people used. But weak passwords are perfectly attackable anyway, without having access to the hashed passwords.

    1. Anonymous Coward
      Anonymous Coward

      Re: Upgrading from salted SHA256?

      But online dictionary attacks are noisy and can be tracked or rate limited, once you have the hash you are only limited by your hardware.

      1. Crazy Operations Guy

        Re: Upgrading from salted SHA256?

        But who the hell cares about serious security on a website like this? It doesn't contain much, if any, private information, its not a bank account FFS, nor is it any site where people will implicitly trust things that you say. The problem comes if a user had used the same password on more important sites and accounts.

        In any case, it wasn't that the passwords weren't properly encrypted; it was that their devs were idiots and left a dev server connected to the internet and connected to their Production database. So they really should be upgrading their firewall and/or employees.

        1. nuked

          Re: Upgrading from salted SHA256?

          "The problem comes if a user had used the same password on more important sites and accounts."

          ...which is about 99% of users; and thus the real problem with these hacks.

          1. Tom 13

            Re: which is about 99% of users

            I've never seen what I consider sufficient documentation of that claim. Yes, we keep getting reports about people using the same passwords in different hacked databases, and especially common passwords like 'password' but never from sensitive databases, only databases people don't care about.

        2. Fred Flintstone Gold badge

          Re: but who the hell cares

          But who the hell cares about serious security on a website like this?

          Overenigineering has saved these guys' bacon. Simply following best practise instead of the far more common "it's good enough" approach also has benefits later on as you're building on solid fundamentals. So thumbs up to them. They did a hell of a lot better than LinkedIn, who SHOULD have cared.

  4. Dom 3

    Site & User salts

    If you do it properly you have a per-user salt in the database and a site-wide salt in a configuration file. That way even if someone compromises the database (as happens so often) then the hashes are immune to any affordable attack. They'd need access to the filesystem as well to make it feasible.

    1. Tom 13

      Re: Site & User salts

      Hard to say since it was a dev server and not a prod server. Dev servers usually have fairly light security because they are supposed to be isolated from real world connections. So if the bad guys had access to the hashed password list on the dev server, there's a fair chance they also had access to the salt hashes as well. Of course since the report doesn't go into those details, it's all speculation. The point in favor of your contention is that the bad guys posted the salted list, not a decrypted list. If they had the hashes you'd think they'd go for the full lulz and post the decrypted list.

      1. Dom 3

        Re: Site & User salts

        "there's a fair chance they also had access to the salt hashes as well" - exactly. Which is why you should have an *additional* sitewide salt that is not in the database. See the other password leak story from today.

  5. the-it-slayer


    Is the salt good enough to go on my chips?

  6. MyronC

    A first?

    Is this the first big password leak that was actually hashed somewhat properly?

This topic is closed for new posts.

Other stories you might like