×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Groupon Deal of the Day: 300,000 Customer Accounts

samzenpus posted more than 2 years ago | from the good-deal dept.

Security 90

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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

90 comments

Groupon Deal of the Day in my pants! (1)

slashpot (11017) | more than 2 years ago | (#36613040)

I have Groupon's best ever Deal of the Day - in my pants!

Re:Groupon Deal of the Day in my pants! (-1)

Anonymous Coward | more than 2 years ago | (#36613076)

Your two inch pecker is hardly a deal.

Re:Groupon Deal of the Day in my pants! (-1)

Anonymous Coward | more than 2 years ago | (#36613344)

You should remeasure, I think you're doubling the actual size.

Re:Groupon Deal of the Day in my pants! (-1, Offtopic)

Lunix Nutcase (1092239) | more than 2 years ago | (#36613358)

I was trying to make the poor guy feel better about himself rather than reminding him that his pecker is smaller than a toddler's.

Re:Groupon Deal of the Day in my pants! (0)

Anonymous Coward | more than 2 years ago | (#36613566)

Seen a lot of toddlers' peckers, have you?

Re:Groupon Deal of the Day in my pants! (0)

Anonymous Coward | more than 2 years ago | (#36613580)

When you are looking to bang other toddlers, that is perfectly acceptable.

Hardly a deal? Are you kidding? (0)

SockPuppetOfTheWeek (1910282) | more than 2 years ago | (#36613404)

2 inches for the price of one! Comes with guaranteed 5-second delivery and free tech support for life!

Re:Hardly a deal? Are you kidding? (0)

Anonymous Coward | more than 2 years ago | (#36621280)

(Score:0)

Tough crowd...

Credit Where Credit Is Due (5, Insightful)

jimmerz28 (1928616) | more than 2 years ago | (#36613042)

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

Re:Credit Where Credit Is Due (4, Insightful)

phantomfive (622387) | more than 2 years ago | (#36613154)

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.

Re:Credit Where Credit Is Due (0)

Anonymous Coward | more than 2 years ago | (#36613236)

There's very little motivation for a website to hash passwords, given that 1) unhashed passwords only pose a security risk to the users - they won't make the site get hacked any more than it already was, and 2) unless the site backend is open source, you don't even know whether passwords are hashed unless it gets hacked.

Don't rely on strangers to protect your passwords. Just use different passwords everywhere; browsers make it easy enough now.

Re:Credit Where Credit Is Due (3, Interesting)

ByOhTek (1181381) | more than 2 years ago | (#36613640)

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...

Re:Credit Where Credit Is Due (1)

praxis (19962) | more than 2 years ago | (#36613926)

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?

Re:Credit Where Credit Is Due (1)

ByOhTek (1181381) | more than 2 years ago | (#36614004)

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.

Re:Credit Where Credit Is Due (1)

AvitarX (172628) | more than 2 years ago | (#36614056)

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

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

Re:Credit Where Credit Is Due (2)

TheSpoom (715771) | more than 2 years ago | (#36614210)

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

Re:Credit Where Credit Is Due (1)

ByOhTek (1181381) | more than 2 years ago | (#36614240)

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

Re:Credit Where Credit Is Due (1)

AvitarX (172628) | more than 2 years ago | (#36616792)

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.

Re:Credit Where Credit Is Due (1)

ByOhTek (1181381) | more than 2 years ago | (#36620868)

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.

Re:Credit Where Credit Is Due (1)

ByOhTek (1181381) | more than 2 years ago | (#36614228)

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.

Re:Credit Where Credit Is Due (1)

AvitarX (172628) | more than 2 years ago | (#36616822)

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.

Re:Credit Where Credit Is Due (1)

ByOhTek (1181381) | more than 2 years ago | (#36620892)

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.

Re:Credit Where Credit Is Due (1)

vux984 (928602) | more than 2 years ago | (#36615914)

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?

Re:Credit Where Credit Is Due (1)

EdIII (1114411) | more than 2 years ago | (#36614304)

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.

Re:Credit Where Credit Is Due (1)

vux984 (928602) | more than 2 years ago | (#36628720)

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.

Re:Credit Where Credit Is Due (4, Insightful)

Qzukk (229616) | more than 2 years ago | (#36613762)

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.

Re:Credit Where Credit Is Due (1)

vux984 (928602) | more than 2 years ago | (#36615988)

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.

Re:Credit Where Credit Is Due (3, Interesting)

ByOhTek (1181381) | more than 2 years ago | (#36613574)

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.

Re:Credit Where Credit Is Due (1)

RichardJenkins (1362463) | more than 2 years ago | (#36617168)

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.

Re:Credit Where Credit Is Due (1)

LordLimecat (1103839) | more than 2 years ago | (#36613428)

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.

Re:Credit Where Credit Is Due (2)

jimmerz28 (1928616) | more than 2 years ago | (#36613630)

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".

Re:Credit Where Credit Is Due (1)

WrongSizeGlass (838941) | more than 2 years ago | (#36613688)

We cant give them an ounce of credit

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

Re:Credit Where Credit Is Due (1)

LordLimecat (1103839) | more than 2 years ago | (#36616346)

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.

Re:Credit Where Credit Is Due (1)

WrongSizeGlass (838941) | more than 2 years ago | (#36616998)

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.

Re:Credit Where Credit Is Due (1)

kronosopher (1531873) | more than 2 years ago | (#36619050)

..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.

Re:Credit Where Credit Is Due (1)

WrongSizeGlass (838941) | more than 2 years ago | (#36626406)

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.

Re:Credit Where Credit Is Due (0)

Anonymous Coward | more than 2 years ago | (#36613724)

my thoughts exactly. no matter how swift the response, this is an intolerable screwup, not a tiny slip

Re:Credit Where Credit Is Due (0)

Anonymous Coward | more than 2 years ago | (#36614364)

All credit goes to the Citibank dev team that they outsourced to.

Oh for the love of ! (1)

james_van (2241758) | more than 2 years ago | (#36613098)

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

Re:Oh for the love of ! (1)

cshark (673578) | more than 2 years ago | (#36613250)

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

Re:Oh for the love of ! (1, Funny)

Sponge Bath (413667) | more than 2 years ago | (#36613524)

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

Re:Oh for the love of ! (0)

Anonymous Coward | more than 2 years ago | (#36614070)

Your kidding right? Microsoft? Industry leader? *snicker* Go back to your windoze box then and let the adults play in a real world environment.

Re:Oh for the love of ! (2)

just_another_sean (919159) | more than 2 years ago | (#36613346)

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.

Re:Oh for the love of ! (1)

marnues (906739) | more than 2 years ago | (#36616452)

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.

Re:Oh for the love of ! (1)

MobileTatsu-NJG (946591) | more than 2 years ago | (#36613468)

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.

Re:Oh for the love of ! (1)

MokuMokuRyoushi (1701196) | more than 2 years ago | (#36614196)

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?

Re:Oh for the love of ! (1)

MobileTatsu-NJG (946591) | more than 2 years ago | (#36622972)

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. :/

Re:Oh for the love of ! (2)

Monchanger (637670) | more than 2 years ago | (#36613664)

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.

Yay? (3, Insightful)

Daetrin (576516) | more than 2 years ago | (#36613184)

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 is on purpose to help justify their IPO! (1)

blahbooboo (839709) | more than 2 years ago | (#36613208)

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

Time to blame Google for hacking! (1)

phantomfive (622387) | more than 2 years ago | (#36613256)

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

Re:Time to blame Google for hacking! (1)

DigiShaman (671371) | more than 2 years ago | (#36613628)

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.

They deserve credit? (3, Insightful)

zill (1690130) | more than 2 years ago | (#36613266)

'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.

Re:They deserve credit? (1)

Aladrin (926209) | more than 2 years ago | (#36613360)

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.

Re:They deserve credit? (2)

callmebill (1917294) | more than 2 years ago | (#36613586)

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.

Re:They deserve credit? (0)

Anonymous Coward | more than 2 years ago | (#36613472)

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

Not to be a Groupon sympathizer, but that's not QUITE right. Although this is certainly a heinous outcome, this was the result of incompetence and/or negligence.. not the actual intention of Groupon.

It's more like you were being careless with a knife, waving it around your friend and then... *SHANK*. Oops..!

The next several seconds would define how you are measured by the world. If your choices are responsible for saving your friends life and essentially offsetting your mistake, you do deserve some credit for that.. as well as credit for being a total f@#$ dumb ass. But as it was done without ill intent, your resulting actions to make it right do hold more weight... at least that's what MY moral compass says *taps the compass*... stupid comp... ahh, there we go.

Re:They deserve credit? (1)

ArsonSmith (13997) | more than 2 years ago | (#36614346)

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.

Re:They deserve credit? (0)

Anonymous Coward | more than 2 years ago | (#36614424)

No, it's better to leave the knife in until adequate medical help is available. Pulling it out can exacerbate the bleeding.

Re:They deserve credit? (1)

marnues (906739) | more than 2 years ago | (#36616786)

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.

path 2 perdition (-1)

Anonymous Coward | more than 2 years ago | (#36613350)

people need to wake up to the fact that cracking passwords, hacking is wide spread n its oly due time wen der ll b big jolt 2 every1. cloud as they say is inevitable so does ur data online. welcome doomsday open handed

Re:path 2 perdition (0)

Anonymous Coward | more than 2 years ago | (#36613600)

Translation please? Maybe actual words, nouns, verbs, etc.

Daily Deal! (3, Funny)

Compaqt (1758360) | more than 2 years ago | (#36613366)

1-day only Groupon:

100% off on the India customer list

Re:Daily Deal! (3, Informative)

Lev13than (581686) | more than 2 years ago | (#36613678)

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

Re:Daily Deal! (0)

Anonymous Coward | more than 2 years ago | (#36625142)

Methinks whoever modded parent informative didn't get the joke....

Title is a Win (-1)

Anonymous Coward | more than 2 years ago | (#36613408)

'nuff said...

Groupon India? (1)

vlm (69642) | more than 2 years ago | (#36613418)

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.

Re:Groupon India? (2)

vlm (69642) | more than 2 years ago | (#36613594)

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.

Re:Groupon India? (0)

Anonymous Coward | more than 2 years ago | (#36615548)

Did you ever tell Groupon any personal info that would allow them to filter out suntanning offers?

I was going to comment on your choices of popular Indian Groupon offers, but I caught the sarcasm in time.

Passwords (1)

devnullkac (223246) | more than 2 years ago | (#36613542)

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?

Re:Passwords (1)

Jaime2 (824950) | more than 2 years ago | (#36613934)

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.

they should've (1)

Anonymous Coward | more than 2 years ago | (#36613588)

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

the next step in the American enterprise... (0)

slick7 (1703596) | more than 2 years ago | (#36613704)

Outsourcing IT security to the lowest foreign bidder. What could go worng?

Best Unsubscribe Experience Ever! (1)

Fibe-Piper (1879824) | more than 2 years ago | (#36613844)

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.

Re:Best Unsubscribe Experience Ever! (0)

Anonymous Coward | more than 2 years ago | (#36614780)

Or you can visit the URL here: http://www.groupon.com/unsubscribe

There is no reason to care about security (1)

thetoadwarrior (1268702) | more than 2 years ago | (#36613856)

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.

Re:There is no reason to care about security (1)

bfree (113420) | more than 2 years ago | (#36614160)

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.

Re:There is no reason to care about security (1)

thetoadwarrior (1268702) | more than 2 years ago | (#36615040)

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.

Re:There is no reason to care about security (0)

Anonymous Coward | more than 2 years ago | (#36615540)

Ha, that assumes equal treatment for actual persons and corporations. As events have proven corporations get "justice", people get thrown down the nearest shaft.

What? (0)

Anonymous Coward | more than 2 years ago | (#36613970)

... long enough to indexed by Google...

That's not english.

That reminds me (1)

chemicaldave (1776600) | more than 2 years ago | (#36614096)

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

Re:That reminds me (0)

Anonymous Coward | more than 2 years ago | (#36615590)

That's like saying you're never going to stand in front of that gun again after it fired.
The damage is done :) Learn from that lesson and don't stand in front of the rest of them.

Yes, they really do deserve credit (0)

Anonymous Coward | more than 2 years ago | (#36621824)

Every company makes mistakes.

Not all companies will fix them properly or put resources into anything but spin control. I work for a webhosting company that's been r00t3d up one side and down the other, where the central access mechanism that provides full access to everything for the staff had been compromised not once, not twice, but repeatedly. The final compromise was the billing system server, where somehow the attacker was trawling employee passwords (and these were strong passwords too) into a text file in /tmp. While they fixed the problem itself and moved the billing system to a new server and implemented some additional access control mechanisms, they never did consider what the attacker had previous access too (answer: everything) and the fact that the attacker was still adding malware code to customer websites on all their servers.

To most slashdotters, this is the ultimate example of everything that can be done wrong. But my employer ignored my repeated warnings, and are still not taking them seriously as I complete my final two weeks of employment. So yes, companies will make mistakes. Everything that you and I as slashdotters know to be Right and Correct and Proper dissolves as soon as there's an organization with production systems involved (commerce must keep going, ya see?). So the fact that they responded quickly to fix it means that they do deserve credit, because there are a lot more companies like my employer that you probably do business with.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...