Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security News

Formspring Hacked - 420,000 Password Hashes Leaked 68

wiredmikey writes with news of yet another business suffering a data breach. From the article: "Formspring, the Social Q&A portal ..., admitted to being breached on Tuesday. The compromise led to the loss of 420,000 passwords, forcing the site to reset all member passwords. Mirroring the recent LinkedIn breach, Formspring said that it was alerted to a forum post that contained 420,000 password hashes. Engineers shutdown the service and confirmed the passwords were indeed theirs. In less than a day, an investigation revealed that the attacker(s) had 'broken into one of our development servers and was able to use that access to extract account information from a production database' .... There have been no reported incidents of individual account compromise, but there were reports of Phishing by some users on Twitter attempting to capitalize on the incident."
This discussion has been archived. No new comments can be posted.

Formspring Hacked - 420,000 Password Hashes Leaked

Comments Filter:
  • 420,000? (Score:5, Funny)

    by Anonymous Coward on Wednesday July 11, 2012 @09:17AM (#40614355)
    420,000? Is that like 100,000 people smokin' the reefer?
    • by vlm ( 69642 )

      420,000? Is that like 100,000 people smokin' the reefer?

      More like 420,000 people use(d) something I've never heard of?

      I wonder if unknown websites would make up some imaginary accounts and intentionally release them to create buzz?

      Its not like there's any penalty for public release of information, and all PR is good PR anyway, so..

      • Re:420,000? (Score:4, Funny)

        by Fnord666 ( 889225 ) on Wednesday July 11, 2012 @10:11AM (#40615005) Journal

        More like 420,000 people use(d) something I've never heard of?

        Exactly. One of the articles even concludes with

        Interestingly, while it gained popularity early on, most users who were reporting that they had received a password reset notice had forgotten they even registered with the service.

      • I wonder if unknown websites would make up some imaginary accounts

        That or they harvested and spammed some 400,000 email addresses using some sort of web promo where you fill in your contact details for a chance to get a freebie.

  • Network Isolation (Score:5, Insightful)

    by Archangel Michael ( 180766 ) on Wednesday July 11, 2012 @09:17AM (#40614365) Journal

    When are people going to get a clue and do proper network isolation of servers ... especially Database servers. There should be no way to attach to a database from outside network. Production and testing servers should all be on sandboxed networks that don't touch the outside.

    • Re:Network Isolation (Score:5, Interesting)

      by vlm ( 69642 ) on Wednesday July 11, 2012 @09:52AM (#40614785)

      I'm old enough to have had that very argument during the original SQL slammer infestation and the replies were along these lines:
      1) Who cares, security costs money but insecurity is free, or free PR advertising anyway.
      2) Thats just one bug, one time, I'm sure its completely secure now
      3) Webservers were not originally built to be secure, but they pitifully bolted some security on and no one blinks at putting them bare on the net, so why worry about putting something originally designed to be secure on the net?
      4) False sense of security means behind the firewall we'll get owned 10 times more often than if we stay paranoid and keep it on the public "dmz". The eternal crunchy outside and soft chewy inside argument. Who knows more about making a DB secure, a DBA or a firewall dweeb? So lets place it on the net and trust the DBA.
      5) 99.9999% of databases getting powned are due to no input sanitizing and buffer overruns and other epic programming fails by those idiot web guys, so we may as well place the mysql server open on the net anyway since the web guys leave the barn door wide open almost all the time anyway.
      6) Our hard coded back door password in the webserver executable closed source app is "password" so I think having the server outside is the least of our concerns. (prioritization)

      Anybody ever hear anything else thats relevant?

      • by Anonymous Coward

        I'm old enough to have had that very argument during the original SQL slammer infestation and the replies were along these lines: 1) Who cares, security costs money but insecurity is free, or free PR advertising anyway. 2) Thats just one bug, one time, I'm sure its completely secure now 3) Webservers were not originally built to be secure, but they pitifully bolted some security on and no one blinks at putting them bare on the net, so why worry about putting something originally designed to be secure on the net? 4) False sense of security means behind the firewall we'll get owned 10 times more often than if we stay paranoid and keep it on the public "dmz". The eternal crunchy outside and soft chewy inside argument. Who knows more about making a DB secure, a DBA or a firewall dweeb? So lets place it on the net and trust the DBA. 5) 99.9999% of databases getting powned are due to no input sanitizing and buffer overruns and other epic programming fails by those idiot web guys, so we may as well place the mysql server open on the net anyway since the web guys leave the barn door wide open almost all the time anyway. 6) Our hard coded back door password in the webserver executable closed source app is "password" so I think having the server outside is the least of our concerns. (prioritization)

        Anybody ever hear anything else thats relevant?

        Imagine if the tanker truck driver felt that way about fire safety. Or if electricians felt that way about getting shocked. Imagine if doctors felt that way about using sterile equipment. Or what if your water utility felt that way about making sure the water was potable (morons saying things like "well I mean bacteria are everywhere so why bother right?").

        If malicious hackers make this kind of stupidity more painful then at least they're doing SOME good in the world. That's what corporations and soc

        • Re: (Score:2, Interesting)

          The doctor analogy is an interesting one - a doctor won't go through a full surgical scrub and use a sterile theatre for giving an innoculation because the risks of introducing a little bacteria into the skin aren't huge, a sterile needle and an alcohol wipe-down are sufficient. In the same way, if you have properly salted hashes using a strong algorithm, and you're not storing personally identifying information (names, CC details etc) then your DB doesn't have to be massively secure. Start storing card d
          • There is a good reason why I'm not hiring you. Ever.

            You do shoddy work, and rationalize it.

            If your chain of authorities aren't clean, nothing is clean, and you risk all.

            • I do work for a client who doesn't have the budget for large commercial level systems. If they ask for something that would require something "shoddy" then I explain that it's not practical at their budget. Example: they wanted to take online payment for tickets. I could have written a custom system to deal with it all but I'm well aware that it would be outside their budget and at the limit of my capabilities, so I pass the problem on to PayPal. On the other hand, if they need due diligence records for
              • Referential integrity is important. I know dbas that use the same complex password for all of their tables, triggers, queries, and apps. Tough password. Once broken, everything is omelet. Pass the cheese.

                Elemental/atomic security, chain of authorities, referential integrity, are all important. There is a place between where your customer will offer you a "price" for something that you'll take, but it's up to par. If you accept that price and deliver substandard infrastructure, then your guilty of many bad t

                • I pretty much agree with everything above.

                  Thanks for coming back with something constructive and thoughtful on top of the snarky comment I thought the previous one might be. I'll give you a little context:

                  I'm mid 30s and have been self employed as a web programmer* for a year now. My main client (a pub/bar sompany) is a previous enployer from over a decade ago, and they've never, ever been into the idea of the internet and having a presence. I'm self-taught from the age of 8.

                  So now your alarm be
                  • Ha, forgotten asterisk. I know, I know, of such things are segfaults made.

                    * Web programmer: I'm not a "web designer", that seems to be people who can use photoshop and wordpress these days. My main tool is customised gedit, plus GIMP and Blender locally, working on LAMP stacks. Web programmer is the simple way to put what I do to a non-geek, I realise I'm probably offending a bunch of real web programmers here.
                  • The "right amount" is a nebulous description based on who's context you're speaking from. At about double your age, I've seen systems taken town in front of my eyes, seen incredibly novel attacks and take-downs, and have watched other systems pounded 24/7 until they should have been bleeding on the floor, but they did their job.

                    Sometimes, you'll find that nothing is foolproof, because fools are so ingenious. That's why diligence counts and efficiency is sometimes sloth or worse: whistling in the dark. Locks

      • Anybody ever hear anything else thats relevant?

        Yes. "IT Doesn't Matter" (http://www.nicholasgcarr.com/articles/matter.html). The argument that IT is just another commodity that should be purchased as cheaply as possible.

        Amusingly, General Motors has apparently now decided that IT matters after all (http://www.itworld.com/it-managementstrategy/285577/gm-set-move-away-it-outsourcing).

    • Surely dev occassionally need a copy of the production DB to replicate bugs and so on? You clean out the passwords and emails and so, but probably on the dev server so at some point there's a copy of the production DB in the dev environment.

      If you have remote workers then your dev environment needs to be accessible over a VPN or something (and so is touching the outside) - Indian workers are cheap after all.

    • by sl4shd0rk ( 755837 ) on Wednesday July 11, 2012 @10:22AM (#40615119)

      When are people going to get a clue and do proper network isolation of servers

      You apparently read alot about security but haven't done much enterprise administration.

      Database servers behind a second DMZ with reverse proxying always look great on paper, and start life out that way but what always happens is there is some "corner case" piece of software which doesn't work with your setup and you need to make an exception. Next, the developer group will explain they've wrote their applications to use "realtime" data and the subset of data you've copied out to the DMZ DB is 6 hours too old. You go to the DB Admin and ask him what it would take to increase the frequency of the Oracle dump and he explains it already takes 6 hours to complete and the dump locks tables so you have to do it at night when Sales and Marketing are not using it. You find out the backups are running after the dump process and the network is quite saturated as it pulls 1500G over the wire to the archive SAN. As a result it takes you another 2 hours to get the subset of data moved out to the DMZ. This whole process takes about 12 hours to run and since you are on the West coast you can't tie up the network or the DB for an additional 2 hours or the Midwest offices can't begin work at 8am. Eventually the boss screams he wants it fixed whatever the cost so someone dual-homes the DMZ database so things can get sucked off the back-end on a separate wire. Sunddenly, developers start using the second nic to connect directly to the DMZ DB but you find out all the added traffic on the second gig nic tops out the old Sun box taking all it's spare CPU cycles with it. The nail in the coffin finally comes in when the AD server in the DMZ is found to have been compromised for over 6 months and has been siphoning data off the Oracle connector to some place in China.

      This is why compromises happen and why we can't have nice things like secure database setups.

      • by Anonymous Coward

        You can't have nice things because reality always wins. No matter what you do, your database will somehow be wired to the Internet. That's its purpose.

        You can VLAN it, make proxies, make one way push-connections such that you replicate the writable system in realtime to read-only nodes in a special DMZ with just one port open to your application server in its own DMZ that has only a service port open to the webserver.

        Bottom line is you just make more hosts to compromise in order to get to the database.

        Now

    • by Charliemopps ( 1157495 ) on Wednesday July 11, 2012 @10:27AM (#40615187)
      And if the production and database servers are "in the cloud"? Kind of hard to isolate them then, aint it?

      I've run into this before. We've got a DB that's hosted in a "cloud service" then we have idiot supervisors/management that want to do training... so they set all their training accounts to
      Username "training1"
      Password "training1"

      We find out, force them to change it. Next thing we know, they're trying to sick VPs on us... "Why are you making it hard for my department to train?!?! It's only a test server!"
      Explaining that it's a duplicate of production doesn't seem to phase them... It's kind of irrelevant which database the hackers get into when they are identical to each other. Calling one "test" is kind of irrelevant from a security standpoint.
  • by txoof ( 553270 ) on Wednesday July 11, 2012 @09:21AM (#40614399) Homepage

    And once again we are reminded that using the same password on every site is a terrible idea for just this reason. I know I'm guilty of recycling a generic password on sites I don't care about, but I fear that my family members are even worse. I'd say there's an 80% chance that my family recycles the same password on both social and banking sites.

    It doesn't help that many password validation routines choke on spaces. Being able to use a passphrase is way easier than trying to remember some random group of characters that just happen to have a high entropy. The Correct Horse Battery Staple [xkcd.com] model is my new favorite for any site that will accept spaces. Sadly, one bank that I have done business with won't even allow a password that is more than 8 characters and only accepts letters and numbers. They try to shore this up with some bogus security questions on the following page, but I don't feel really "secure."

    What other password strategies do you all use to make sure you keep reasonably secure? I eventually gave in to using KeePass to keep my less frequently but more important passwords secure.

    • by Theophany ( 2519296 ) on Wednesday July 11, 2012 @09:24AM (#40614437)
      Whilst I agree with all of the above, I think the *real* takeaway from this should be "don't use shitty websites like Formspring, for fuck's sake."
    • Personally I much prefer serves like pwdhash.

      Remember one base password across all sites and it'll convert it into a hash for you, so even if you have a key-logger installed it'll only record the base, and not the hashed one.

      • by kav2k ( 1545689 ) on Wednesday July 11, 2012 @09:33AM (#40614537)
        So, if I understand the idea correctly, once the keylogger has the base password, all derived passwords are screwed? It protects against hash/unencrypted password leaks, but makes the base password too valuable.
        • Once the keylogger is on your machine, all passwords are screwed anyway. As is your CC#, billing address, name, CCV2 code, etc.
      • by Calos ( 2281322 ) on Wednesday July 11, 2012 @09:39AM (#40614607)

        Yep, I love pwdhash. It's portable without worrying about leaving a password database on a thumbdrive or in the cloud, it can generate long, site-unique passwords while using the same base password. Pwdhash is pretty nice in that it is sensitive to stupid websites that don't allow special characters, too - if you put a special in the password you supply, it very likely (but not necessarily) include one in the password it generates. If you don't put specials in the user-supplied portion, the output is just alphanumeric. Of course, there are still the stupid websites that want passwords to be 12 characters or less, and/or have to start with a letter, and/or other asinine rules. A downside though is that there is a maximum length for the passwords pwdhash generates, 22 chars if I remember correctly, but at this point, I don't think that's really an issue.

        Still don't recommend actually using the same base password for everything, of course.

        The other cool thing about pwdhash (and potentially, similar services too) is that they don't have to be used on websites. You can use it to generate passwords for, say, your wireless. Do something like the SSID in place of the website, then supply your part of the password.

        Pwdhash [pwdhash.com]

    • by vlm ( 69642 ) on Wednesday July 11, 2012 @09:41AM (#40614627)

      I know I'm guilty of recycling a generic password on sites I don't care about, but I fear that my family members are even worse. I'd say there's an 80% chance that my family recycles the same password on both social and banking sites

      I have one password for each class of security. Ultra critical life savings depends on it has one which is only used on two sites anyway. Then there's /. and sites like it which has another "I can't lose money, but I'd be pissed if someone stole my account" password. Finally "I can't believe these morons force me to create an account for their cruddy site F those idiots the password for moron sites is password123"

      I believe that websites that demand account creation when there is no need to create an account, like to order stuff, or view pages, are a social disease that should be stamped out. Aggressively if necessary. Not because one POS automotive parts site demanding I "create an account" just to make a single item purchase one time in my life is inherently evil, but because making a billion people make hundreds of accounts each, many of which will be stolen IS evil. This is no different than the argument where "if I occasionally accidentally dump out a little used motor oil its no big deal, but if the whole planet dumped all their used oil, it would be a freaking disaster"

      • Hey me too! Except at the top level (e.g. banking, email), every site has a unique password. At the lowest level, all the forums and miscellany have the same password.

        • by Bigbutt ( 65939 )

          The "identity sites" have different password model vs a same password. They are associated with me and my information. It would blow if my account started spamming 5 or 6 forums that I use.

          [John]

    • All of my banking passwords are the weakest ones. Most of the banking sites will not allow a full alphabet of special characters (American Express only has something like 6 different special characters you can use). I'm like WTF, is this a banking site or not?

      • In Finland (probably in many other nearby countries too), for banks it's customary to get a printed sheet of one-time tokens mailed at home. There is usually also an extra verification step when you are about to perform some action such as making a transfer.
    • by Tridus ( 79566 )

      People need more useful advice then this, because "use different passwords everywhere" is so impractical for most of the public that it's ignored.

      More and more I don't think smaller websites like this should even store passwords. Use external authentication providers like Facebook or Google accounts instead. We've seen too many cases where companies that aren't huge don't have security that can stand up, and given budget they never really will.

    • by Bigbutt ( 65939 )

      The best part about the security questions is the answers are easy to find (in general). What's your mother's maiden name, where were you born, etc are many times easily available. When I have to use those, I pick something totally different from the true answer. Then it doesn't matter which security question I have. I do record them in my password database though :)

      [John]

    • I use Keepass and love it but, given that I use the generate function for passwords, I am now totally dependent on it - along with relying on the browsers to remember the more common non-banking passwords. Given that even my backups are at the same site (home), I really need to finally get a bank deposit box, but I balk at yet another bill.
  • by InvisibleClergy ( 1430277 ) on Wednesday July 11, 2012 @09:31AM (#40614523)

    I know it's a Q&A site, but ForumSpring Engineers really shouldn't have answered the question, "How do I hack the ForumSpring servers?"

    • ForumSpring Engineers really shouldn't have answered the question, "How do I hack the ForumSpring servers?"

      Heh, I refer you to A Logic Named Joe [baen.com]. It predicted the personal computer, the internet, search engines, and the real uses which most people would find for them. In 1946. Nineteen. Forty. Six.

  • by Anonymous Coward

    It sounds like bad configuration management. I'm guessing the database passwords are the same for the dev servers as they are for the production servers. Bad, bad, bad...

  • At least its hashes and not a clear text file like a certain video game system we all know and love.
  • Were the hashes created with salt, randomized per user? It sounds like they were, which of course is in contrast to the LinkedIn breach.
    • by Gavin Scott ( 15916 ) on Wednesday July 11, 2012 @10:59AM (#40615585)

      The linked SecurityWeek articles includes the quote:

      “We were able to immediately fix the hole and upgraded our hashing mechanisms from sha-256 with random salts to bcrypt to fortify security."

      Which suggests that they were indeed salting the passwords. Assuming this was actually done, and done in a reasonable manner, then in theory there should actually be little or no risk from this breach I would think. But then I don't know why they would feel the need to immediately replace their hashing mechanism...

      G.

      • by mmajor ( 218163 )

        Salting just defends against precomputed hashes (rainbow tables). Using a slower algorithm such as bcrypt defends against brute force attacks.

        Case in point: I cranked through LinkIn's 6+ million SHA hashes using a dictionary of around ~20 million words (not counting JtR's manipulation rules). The total runtime was maybe half an hour. Using bcrypt makes brute force attacks much less practical. It's also good practice to iterate your hashing algorithm, each time feeding the resultant hash as input. Running sh

  • Maybe I'm oldschool, but I seem to remember these configurations being really common in production environments when I was a young programmer:
    • Java-based website: INTERNET [firewall forwarding ports 80 and/or 443] WEB SERVER(s) [firewall forwarding port 8080] APPLICATION SERVER(s) [firewall forwarding ports for users to access production RDBMS] DATABASE SERVER(s)
    • Light PHP/Perl/Python/etc script-based website: INTERNET [firewall forwarding ports 80 and/or 443] WEB SERVER(s) [firewall forwarding ports for us
  • Start using OpenID

Computer programmers do it byte by byte.

Working...