Slashdot Mirror

← Back to Stories (view on slashdot.org)

Groupon Deal of the Day: 300,000 Customer Accounts

Posted by samzenpus on from the good-deal dept.

itwbennett writes "The customer database of Groupon's Indian subsidiary was published, unsecured and unencrypted, on the company's site for long enough to indexed by Google. Australian security consultant Daniel Grzelak, Tweeted the news and also notified Groupon, which 'was amazing at providing a swift and full response,' Grzelak said on Twitter. 'They deserve credit for their reaction.'"

64 of 90 comments (clear)

  1. Credit Where Credit Is Due by jimmerz28 · · Score: 5, Insightful

    I guess they also "deserve credit" for allowing it to occur in the first place?

    1. Re:Credit Where Credit Is Due by phantomfive · · Score: 4, Insightful

      Exactly. If you really stretch, putting the user-names online could be considered an (unusually bad) accident. But storing unhashed passwords anywhere is inexcusable. This is basically an announcement to the world that they have no security practices whatsoever.

      --
      "First they came for the slanderers and i said nothing."
    2. Re:Credit Where Credit Is Due by LordLimecat · · Score: 1

      By your logic, every response is the same-- i mean, if they screwed up, who CARES whether they respond quickly and acknowledge the problem? We cant give them an ounce of credit, so they might as well go all out and release the password database too, right?

      Not to minimize the extent of their fail, but seriously, attitudes like yours hardly encourage vendors to respond to breaches and vulnerability reporting responsibly.

    3. Re:Credit Where Credit Is Due by ByOhTek · · Score: 3, Interesting

      In general practice, things that target cheapskates for money tend to be *very* poor quality in any area where dropping quality shaves off a buck of cost - the profit margins tend to be low, and every saved dollar is necessary. Better to stay in business until caught, than make no profit at all.

      --
      Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
    4. Re:Credit Where Credit Is Due by jimmerz28 · · Score: 2

      If I had said they "only" deserve this credit than maybe you'd have a point, however, I said "also" since this article was supposed to be a sweeping appraisal of a response to a rather disgusting action. They deserve credit for both actions, not just their "brush this under the rug asap".

    5. Re:Credit Where Credit Is Due by ByOhTek · · Score: 3, Interesting

      bullshit on #2.

      I admin a closed sourced app with a web portal, and I can tell you the passwords are damn well hashed and salted. It doesn't take much having to fiddle around with the various data files enough in the lines of customizing things, to see where and how the passwords are stored.

      In other cases, where the database is used to store this, the user account table(s) in the database usually have a cryptically named column such as "pass", "pass _hash", etc. that couldn't have anything to do with the password...

      --
      Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
    6. Re:Credit Where Credit Is Due by WrongSizeGlass · · Score: 1

      We cant give them an ounce of credit

      An ounce of credit doesn't fix several pounds of irresponsible behavior and lax security.

    7. Re:Credit Where Credit Is Due by Qzukk · · Score: 4, Insightful

      2) unless the site backend is open source, you don't even know whether passwords are hashed unless it gets hacked

      I tell it I forgot my password. If it emails the password back to me, it's stored as good as plain text. Then I change it to line noise and never go back.

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    8. Re:Credit Where Credit Is Due by praxis · · Score: 1

      I think his point was the user doesn't know that. If they know you are using a well-known open-source backend that they know hashes passwords, then they know. If you are a closed-source proprietary app that does not publish their source code for the end-user to read, how is he to know if you properly treat passwords?

    9. Re:Credit Where Credit Is Due by ByOhTek · · Score: 1

      Working on such in my personal time, I can, again call BS.

      It would be somewhere between easy and trivial on most, to remove password hashing. It's a problem I've been trying to solve myself. I finally came to the conclusion that the hashing has to be done in javascript on the client side, or otherwise by the user, without an unhashed password being sent over the wire, for the user to be sure their unhashed password isn't sent.

      --
      Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
    10. Re:Credit Where Credit Is Due by AvitarX · · Score: 1

      If it is hashed client side you've defeated the purpose.

      Now cracking the database reveals the info needed to login once more.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    11. Re:Credit Where Credit Is Due by TheSpoom · · Score: 2

      Plus, to encrypt client-side, you'd have to give away your salt.

      --
      It's better to vote for what you want and not get it than to vote for what you don't want and get it.
      - E. Debs
    12. Re:Credit Where Credit Is Due by ByOhTek · · Score: 1

      Not if your site hints on how the user should salt their password (in a manner unlikely to be duplicated on other sites).

      Also, there's nothing preventing the site from running a second hash, again fixing the issue, and now the user has the advantage of knowing their password isn't stored clear text.

      --
      Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
    13. Re:Credit Where Credit Is Due by ByOhTek · · Score: 1

      You don't have to use the same salt on every user. Heck, you don't even have to use the same salting pattern.

      --
      Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
    14. Re:Credit Where Credit Is Due by EdIII · · Score: 1

      You missed his point. I don't store passwords in the database encrypted or hashed or salted or with a little sprinkling of lemon pepper.

      Why would I? To say it is inexcusable (GP of who you replied to) is being simplistic. Encrypting field values in a database is not a security panacea, and letting yourself have that false sense of security is what is inexcusable. Once I am inside your inner network your encrypted field values are not going to stop me for very long.

      Security comes in layers......

      The user is on a SSL encrypted page when they enter the password. I realize there has been some recent developments that make me question just how secure a certificate really is, but I have done my part to secure the communication between me and the user.

      Additionally, we use javascript to encrypt the more sensitive AJAX back to the web servers. Of course I realize that the threat can come from the users too, so that just provides security for the user, not for us. From there they make another secure API call to a whole different set of servers that are separate from the web servers. Hack a web server and all you really get is the ability to make direct API calls. That does not really get our panties in a bunch either because we allow some customers to have their own credentials and rights all the way down to the functions themselves. No different really, except you got the API credentials for that webserver. Congrats. You still can't access the databases or run SQL statements, and no API calls exist that will allow you to pull a "list" of all users, profiles, passwords, etc. We are also SQL Injection proof. Yes, I said proof. It's not impossible by any stretch of the imagination and is actually quite easy. You can pass data to API calls all day long attempting to do so and will just fail. It's not rocket science on how SQL Injection works. Validate data, inspect the statement, don't allow characters like the ' symbol, and when absolutely required just base64 encode the whole string or blob when it gets added to the statement. You would just back a field value in your call with your SQL Injection attempt :)

      In order to get to the database files themselves you would need to compromise the API servers which are the only servers with direct access to all the database servers on their own network. Only at that point would you even have the ability to run your own SQL statements, or grab one of the customer databases.

      So once again, if I already have multiple layers of security, and I don't rely on open source hacked together out of the box but our own code bases, why the extra step of encrypting the database field?

      Granted, it is an additional layer of security. However, there are no API calls that even exist that will give a response document back with the password. You can get limited profile information based on your API credentials, limited to the databases and customers that you are allowed access to.

      Passwords and financial information are *never* sent back in any API call at all. Ever. Nobody needs it, and even customer service only gets the last 4 of a credit card or social, not the whole thing.

      Saying that you need to encrypt all passwords in the database is being simplistic. Security comes in layers, and at least in our case, if you CAN make a SQL query against a database directly and retrieve all the record data we are already deeply screwed. That is because you will have already owned us to the point that the whole inner networks are at your disposal, and you long ago got past the DMZ and whatever security our firewalls and hardened API servers were providing.

      P.S - We are entirely open source with our platforms. The difference is, that we don't just take a plug-in and "go with it". We write most of our own code and heavily modify and inspect all the open source code we use for our projects. In some cases, we have written whole systems from scratch.

    15. Re:Credit Where Credit Is Due by TheCouchPotatoFamine · · Score: 1

      how about storing a hash of the client generated hash? Hash both ends?

      --
      CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
    16. Re:Credit Where Credit Is Due by vux984 · · Score: 1

      If they know you are using a well-known open-source backend that they know ,,, ... that it would be trivial for anyone with a bit of programming experience to comment out the calls to hash the passwords during creation and authentication, enabling them to be stored in plaintext.

      If you are a closed-source proprietary app that does not publish their source code for the end-user to read, how is he to know if you properly treat passwords?

      Unless the website host gives you access to the live servers running the site to inspect the source code, how are you to know if the passwords are properly treated?

    17. Re:Credit Where Credit Is Due by vux984 · · Score: 1

      I tell it I forgot my password. If it emails the password back to me, it's stored as good as plain text. Then I change it to line noise and never go back.

      Right, and if it makes you reset it without sending it back to you... all you know is that it MIGHT be hashed.

      It'd be pretty trivial to write a system that doesn't hash the passwords, but doesn't send them back to the user as part of the password recovery mechanism.

      Taking any 'good' system, and commenting out the calls to hash the password would pretty much do it.

    18. Re:Credit Where Credit Is Due by LordLimecat · · Score: 1

      A good response to a mistake is a heck of a lot better than no response; this is why Im willing to cut Google some slack after the WiFi foul-up, and cut Microsoft some slack when they make a really decent product. One mistake does not mean the end of any consideration of merit.

      My goodness, I hope you never make any mistakes, if you mean to say (as your statement implies) that there is no return from a screwup.

    19. Re:Credit Where Credit Is Due by AvitarX · · Score: 1

      If you use a separate. Salt for every user the salts will neede to be stored in the database, I imagine this degrades their value in the instance where the db is hacked (usuallly the salt is stored in a file I think).

      Hashing on the client turns the hash into the passwo defeating the value of the with the exception perhaps of cross site reused passwords (but if it were common practice, the hashed password would be the same in various places, with the exception of salts that are now made public.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    20. Re:Credit Where Credit Is Due by AvitarX · · Score: 1

      There password becomes the hash they generate and send to the server, if it is not hashed on the server, a db comprimise reveals what is needed to log in, we are back to trusting the site.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    21. Re:Credit Where Credit Is Due by WrongSizeGlass · · Score: 1

      My goodness, I hope you never make any mistakes, if you mean to say (as your statement implies) that there is no return from a screwup.

      Of course I make mistakes, and people (and companies) can make a return from a screw up, but securing user data after it's been made public on Google for the world to see forever after does not make up for the poor design, implementation and security that took place up front. At some point the display of such poor judgement and minimal (if any) skill should make it clear that they shouldn't be in a position of such responsibility in the first place, let alone now.

      If I display such utterly poor judgement and skill while driving the state can and will (and should) take away my driving privileges. In this case the entire management and security team should be replaced. I'd be happy to drive them to the airport, but they may not want to get into my car.

    22. Re:Credit Where Credit Is Due by RichardJenkins · · Score: 1

      I think it's right to go further and say that in general recording your users' passwords without suitably salting them and passing them through a secure hasing algorithm is, unless you have an extremely robust justification, antiethical to claims or basic IT security competency.

      Tid bit: I remember an application once (perhaps a linux distribution?) that had an embarrassing bug where the installer asked you to enter a password and which could end up recorded in a log file. Silly errors always trounce best practice.

    23. Re:Credit Where Credit Is Due by kronosopher · · Score: 1

      ..securing user data after it's been made public on Google for the world to see forever after does not make up for the poor design, implementation and security..

      Neither TFS nor any previous poster said that GroupOn's effective, albeit untimely, response in any way abdicates them from the responsibility for the leak. TFS simply meant that GroupOn's immediate reaction(once they knew what had happened) deserves some consideration.

      they shouldn't be in a position of such responsibility in the first place, let alone now

      I'm guessing that you mean that if a software developer can't write 100% secure software the first time, said developer shouldn't develop software at all?

      the entire management and security team should be replaced

      Please correct me if I'm not understanding this correctly, but it seems to me that you're advocating strict government oversight of the entire software industry.

    24. Re:Credit Where Credit Is Due by ByOhTek · · Score: 1

      So, that would prevent a second salt/hashing from being applied?

      No.

      Anything done server side, can still be done server side, but now the client also has the ability to keep the protection of his/her password in his/her own hands.

      --
      Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
    25. Re:Credit Where Credit Is Due by ByOhTek · · Score: 1

      Please re-read the second chunk of text in my post, until you realize the problem you posted was already covered and taken care of.

      Here's a hint if you need some assistance, the opposite of the bolded text was explicitly stated.

      There password becomes the hash they generate and send to the server, if it is not hashed on the server, a db comprimise reveals what is needed to log in, we are back to trusting the site.

      --
      Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
    26. Re:Credit Where Credit Is Due by WrongSizeGlass · · Score: 1

      Neither TFS nor any previous poster said that GroupOn's effective, albeit untimely, response in any way abdicates them from the responsibility for the leak. TFS simply meant that GroupOn's immediate reaction(once they knew what had happened) deserves some consideration.

      Too little too late IMHO. Security should never be an afterthought.

      I'm guessing that you mean that if a software developer can't write 100% secure software the first time, said developer shouldn't develop software at all?

      Not what I said and not what I meant. Their 0% security approach is completely unforgivable. Software developers should make every reasonable effort to secure their products, websites and data. Truly 100% secure isn't obtainable because OS, 3rd party software and other vulnerabilities beyond their control come into play.

      Please correct me if I'm not understanding this correctly, but it seems to me that you're advocating strict government oversight of the entire software industry.

      No, I'm advocating strict shareholder oversight of the entire software industry. Management has a responsibility to those whose data they gather as well as the shareholders whose investments they are sworn to protect from irresponsible and negligent actions. Customers and users can and should vote with their feet, but shareholders should vote with their proxies.

    27. Re:Credit Where Credit Is Due by praxis · · Score: 1

      Yes, you are right. In both cases the end-user doesn't know.

    28. Re:Credit Where Credit Is Due by vux984 · · Score: 1

      I don't store passwords in the database encrypted or hashed or salted or with a little sprinkling of lemon pepper.

      Just hashed and salted.

      Why would I? To say it is inexcusable (GP of who you replied to) is being simplistic

      Not at all. Its inexcusable not to do this.

      Saying that you need to encrypt all passwords in the database is being simplistic.

      HASH not ENCRYPT

      Security comes in layers, and at least in our case, if you CAN make a SQL query against a database directly and retrieve all the record data we are already deeply screwed.

      You probably are, but if my password is hashed and salted, I'm only screwed on your site.

      That is because you will have already owned us to the point that the whole inner networks are at your disposal, and you long ago got past the DMZ and whatever security our firewalls and hardened API servers were providing.

      Yes, but if you propery salted and hashed the password, whoever owned you still wouldn't have anyones passwords short of brute forcing them.

      Most people reuse passwords because they don't have the ability or desire to remember hundreds, and many of them are for things that aren't that important ... like slashdot. So if your hosting slashdot and you get owned, it would be nice if you didn't give the hacker my password because i use that password to access a couple other forums as well.

      Its inexcusable for you to store my password. You don't need it. You need a salted hash of it. If all you have is a salted hash of it, no matter how badly you get owned, at least you didn't give up my password, which may be (and probably is) used somewhere else.

      How many people use the same password for WoW as they do on a random WoW forum for example... forum gets hacked... they're WoW character gets hacked.

      You can argue legitimately that they shouldn't have used the same password in both places, but if you'd salted and hashed their password, you wouldn't have amplified the damage of their poor decision. .... and since you don't even need to store the actual password its inexcusable that you would.

  2. Oh for the love of ! by james_van · · Score: 1

    there is a serious issue going on lately in IT. sony, dropbox, now groupon. who's next?

    1. Re:Oh for the love of ! by cshark · · Score: 1

      This is what happens when you don't think about security when you build your apps and servers.

      --

      This signature has Super Cow Powers

    2. Re:Oh for the love of ! by just_another_sean · · Score: 2

      Yeah, except for in this case the "hackers" were Google. Will anyone pay attention to shoddy security on the web now or we will see new legislation introduced that makes indexing the web illegal? At this point, as absurd as that statement sounds, I just don't know.

      --
      Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
    3. Re:Oh for the love of ! by MobileTatsu-NJG · · Score: 1

      there is a serious issue going on lately in IT

      Just for clarification: It's the reporting of it that's gone up, not the incidents of it. S'not like everybody decided to downgrade security.

      --

      "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

    4. Re:Oh for the love of ! by Sponge+Bath · · Score: 1, Funny

      More companies should follow the best practices of industry leaders like Microsoft.

    5. Re:Oh for the love of ! by Monchanger · · Score: 2

      Lately? Security has never been a sufficiently significant concern to managers or even technical people. Do you think decades-old problems like SQL injections and buffer overflows are extinct? And this "security breach" was a matter of putting sensitive data in a publicly accessible directory.

      I blame our short-term memory for this epidemic. The prevalence of short-term thinking (you want how many billion bloody dollars for this unproven business model???) likely deserves some "credit" too.

    6. Re:Oh for the love of ! by JonySuede · · Score: 3, Insightful

      I feel like I am into bizzaro world as this phrase now evaluate to true....

      --
      Jehovah be praised, Oracle was not selected
    7. Re:Oh for the love of ! by MokuMokuRyoushi · · Score: 1

      Couldn't recent levels of hacking or hacking reports be due to upgraded hacking rather than downgraded security? Maybe I'm wrong, I'm not in the industry, but that seems like basic logic - after Anon, everyone started jumping on the bandwagon. No?

      --
      Humans are terrible replicators of Godly things.
    8. Re:Oh for the love of ! by Killjoy_NL · · Score: 1

      Personally, I can't remember any big security screw-ups like this one from MS, can you?

      --
      This is the sig that says NI (again)
    9. Re:Oh for the love of ! by marnues · · Score: 1

      That's some obvious FUD if I ever heard it. Google did exactly what Google does. If there is a "hacker", it was the ops team that opened the web server up to a plain text file. I personally find the it disingenuous to call someone a "hacker" in this case. The GP was referencing the poor security of these companies, nothing about hacking or whatever.

    10. Re:Oh for the love of ! by MobileTatsu-NJG · · Score: 1

      D'oh.

      I phrased that reallllly badly. I basically said "the level of hacking is the same" when I was thinking "the vulnerabilities leaving IT available to hacking are the same."

      I'm sorry, you're right. What I said and what I meant were two different things. :/

      --

      "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

  3. Yay? by Daetrin · · Score: 3, Insightful

    Well the one good thing we definitely seem to have gotten out of the Sony fiasco is the corporate realization that any company with a significant "social" or consumer side is much better off announcing at least some details as quickly as possible as soon as they realize they've been hacked.

    One hopes that those same corporations have _also_ learned that better security is necessary, but even if they have we're not going to see the effects of _that_ lesson for awhile.

    --
    This Space Intentionally Left Blank
  4. This is on purpose to help justify their IPO! by blahbooboo · · Score: 1

    Without that influx of IPO cash how can they fix these security holes???

  5. Time to blame Google for hacking! by phantomfive · · Score: 1

    It is Google's fault for hacking! Sadly, it wouldn't be the first time Google has been sued for that.

    --
    "First they came for the slanderers and i said nothing."
    1. Re:Time to blame Google for hacking! by DigiShaman · · Score: 1

      That's equivalent to google taking a street picture of a house with its front door open exposing valuables. Several weeks later, that house gets robbed of only the items in view. The motive and scope of the crime is a moot point. The point is that once you leave something available to the public, it's up to the owner to minimize the risk.

      --
      Life is not for the lazy.
    2. Re:Time to blame Google for hacking! by iiiears · · Score: 2

      @DigiShaman Exactly.

      If your favorite site has leaked passwords a quick search will find a dozen sites with lists.
      Curious about what a typical "secret" "password" is this site will tell you in "1234567" "hunter2"
      http://stormsecurity.wordpress.com/2009/10/12/check-if-your-email-account-has-been-exposed/

      --
      15TW = 15,000 Nuclear Reactors. (Approx. one accident a month.)
  6. They deserve credit? by zill · · Score: 3, Insightful

    'They deserve credit for their reaction.'

    That's like saying if I quickly pull the knife out after stabbing someone, I deserve credit for my quick reaction.

    1. Re:They deserve credit? by Aladrin · · Score: 1

      No no, only if you tell them you stabbed them and apologize.

      Or for a car analogy, it's like slashing someone's tires, then telling them as soon as you can find them.

      The damage was done here, but nothing was (or can be) done to fix the problem.

      --
      "If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
    2. Re:They deserve credit? by callmebill · · Score: 2

      Or more like, you gave the car and keys to the valet, and they left the keys in the car while they dozed at their post. Your car (or your GPS) was stolen.

    3. Re:They deserve credit? by ArsonSmith · · Score: 1

      only if you rush them to the hospital and explain the accident...

      Otherwise your analogy is saying they gave this access on purpose. They may have, although I personally doubt it.

      --
      Paying taxes to buy civilization is like paying a hooker to buy love.
    4. Re:They deserve credit? by marnues · · Score: 1

      We could discontinue the absurd idea that companies are a singular entity. Someone in IT should be sacked and someone in PR (or hopefully an Exec as this should be a big deal in GroupOn) has earned their bonus for the year. GroupOn as an entity though is definitely going to hurt from this.

  7. Daily Deal! by Compaqt · · Score: 3, Funny

    1-day only Groupon:

    100% off on the India customer list

    --
    I'm not a lawyer, but I play one on the Internet. Blog
    1. Re:Daily Deal! by Lev13than · · Score: 3, Informative

      It won't be quite that bad - experts predicted that over 1/3 of the passwords will never get used.

      --
      When you have nothing left to burn you must set yourself on fire
    2. Re:Daily Deal! by Kamiza+Ikioi · · Score: 1

      The deal is on!

      --
      I8-D
  8. Groupon India? by vlm · · Score: 1

    The customer database of Groupon's Indian subsidiary was published

    Does Groupon-India offer good deals or just junk like we get around here? All we have around here is suntanning offers (hello, look at my skin color?, they should filter for stuff like that) and waxing salons (uuh, no) and some restaurant over 40 miles away that probably isn't any different than the other 2000 restaurants I'd have to drive past to get there.

    My guess is Groupon-India would probably offer real popular deals like genuine grass-fed beef hamburgers and Pakistani restaurant special offers.

    --
    "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
    1. Re:Groupon India? by vlm · · Score: 2

      Whoops, I suppose I should have checked todays offers before posting.

      We have a $50 basic car detailing marked up to $210 then back down as a deal to $75 a mere 25 miles from my house in a scary neighborhood, a "detoxifying foot bath" sounds like just a step above patent medicines and faith healing, and a speed reading class 30 miles from home that normally retails for a mere $40/hour (WTF? $40/hr for a reading class?) and now is "on sale" for a mere $10/hr.

      I guess they pulled the sun tan salons when they realized its warm enough to ... just lay outside.

      --
      "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
  9. Re:path 2 perdition by bsharp8256 · · Score: 1

    It's amazing how smart kids are these days. This 5-year-old is already on Slashdot!

  10. Passwords by devnullkac · · Score: 1

    Perhaps this gets mentioned daily when these exposures happen, but I guess I just don't understand why cleartext passwords are being stored server side anyway. I'm no security researcher, but surely one-way hash algorithms and password validation techniques have advanced to the point where exposure of the raw password data can't immediately lead to the original password being compromised? Are the authors of these large scale systems unaware or lazy, or are they actually dealing with a problem that's beyond my comprehension and can't actually be solved with current technologies?

    --
    What do you mean they cut the power? How can they cut the power, man? They're animals!
    1. Re:Passwords by Jaime2 · · Score: 1

      It happens enough to require some concrete explanation other than ignorance. There could be a few possible explanations, from the customer service department demanding to know user's passwords in order to help customers more quickly, to someone in IT deciding storing clear-text password will allow a simpler shift from one back-end to another at some time in the future. Since these reduce a small amount of pain on the organization and the loss of passwords brings no pain (except to their customers), the insecure method wins the trade-off.

      BTW, I am currently in the middle of a back-end migration where having hashed passwords is causing me some pain. My life would be much easier if these passwords were stored in clear text. I realize that this is simply the cost of reasonable security, but some people might see it differently, especially if they don't value their customers at all.

  11. they should've by Anonymous Coward · · Score: 1

    Perhaps they should've outsourced their coding to the US.

  12. Best Unsubscribe Experience Ever! by Fibe-Piper · · Score: 1

    Not kidding here. If any of you slashdotters are subscribed to groupon ; you have to do this - even if you sign up again later. It's worth it. Unsubscribe completely.

    What you will see is a VERY clever "We're sorry to see you go..." screen with an awesome Easter egg embedded in there. They may have shot themselves in the foot with this. I want to unsubscribe again and again.

    --
    I went to battle M.C. Escher, but drew a blank.
  13. There is no reason to care about security by thetoadwarrior · · Score: 1

    Companies have proven over and over that they will not produce secure software. They won't even make a decent attempt at it. Something needs to be done to put much more pressure on companies to put more focus on security rather than knocking out features every week or using low paid under skilled developers.

    1. Re:There is no reason to care about security by bfree · · Score: 1

      Some RIAA level figures would do the trick, so if it is $150,000 per song for allofmp3.com then surely $150,000 per user would be appropriate? So Sony and their 70 million leaked user accounts would only have cost them $10.5 trillion and Groupon would get a bill for $45 billion. Even dropping to $200 per song/user (a figure a judge came up with in an "innocent infringement" case for non-commercial music sharing) Sony would have faced a bill for $14 billion and Groupon $60 million.

      --

      Never underestimate the dark side of the Source

    2. Re:There is no reason to care about security by thetoadwarrior · · Score: 1

      Not a bad idea really. If one measly song can be worth so much then surely a person's identity should be worth as much if not more.

  14. That reminds me by chemicaldave · · Score: 1

    to never sign up for Groupon, in addition to a Sony account.