Groupon Deal of the Day: 300,000 Customer Accounts 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.'"
Credit Where Credit Is Due (Score:5, Insightful)
Re:Credit Where Credit Is Due (Score:5, Insightful)
Re:Credit Where Credit Is Due (Score:4, 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...
Re: (Score:2)
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: (Score:2)
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: (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.
Re: (Score:3)
Plus, to encrypt client-side, you'd have to give away your salt.
Re: (Score:2)
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: (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.
Re: (Score:2)
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: (Score:2)
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: (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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
Yes, you are right. In both cases the end-user doesn't know.
Re: (Score:2)
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
Re: (Score:2)
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 al
Re:Credit Where Credit Is Due (Score:5, 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.
Re: (Score:2)
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 muc
Re:Credit Where Credit Is Due (Score:4, 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.
Re: (Score:2)
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 pr
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
We cant give them an ounce of credit
An ounce of credit doesn't fix several pounds of irresponsible behavior and lax security.
Re: (Score:2)
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: (Score:2)
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
Re: (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: (Score:2)
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 w
Oh for the love of ! (Score:1)
Re: (Score:2)
This is what happens when you don't think about security when you build your apps and servers.
Re: (Score:2, Funny)
Re:Oh for the love of ! (Score:4, Insightful)
I feel like I am into bizzaro world as this phrase now evaluate to true....
Re: (Score:2)
Personally, I can't remember any big security screw-ups like this one from MS, can you?
Re: (Score:3)
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: (Score:2)
Re: (Score:2)
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: (Score:1)
Re: (Score:2)
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: (Score:3)
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? (Score:4, Insightful)
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! (Score:2)
Without that influx of IPO cash how can they fix these security holes???
Time to blame Google for hacking! (Score:2)
Re: (Score:2)
Re: (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/ [wordpress.com]
They deserve credit? (Score:4, 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.
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:1)
Daily Deal! (Score:4, Funny)
1-day only Groupon:
100% off on the India customer list
Re:Daily Deal! (Score:4, Informative)
It won't be quite that bad - experts predicted that over 1/3 of the passwords will never get used.
Re: (Score:2)
The deal is on!
Groupon India? (Score:2)
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: (Score:3)
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 re
Passwords (Score:2)
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 beyon
Re: (Score:2)
they should've (Score:1)
the next step in the American enterprise... (Score:1)
Best Unsubscribe Experience Ever! (Score:2)
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.
There is no reason to care about security (Score:2)
Re: (Score:2)
Re: (Score:2)
That reminds me (Score:2)