We have begun notifying our subscribers and advising them to change their Sosasta passwords as soon as possible. We will keep our Indian subscribers fully informed as we learn more.
This is a lie. Neither I nor my brother have heard from them. Keep in mind that this happened on Friday and it's already Tuesday here. In the meantime, I have been spammed about deals that I don't care about through e-mail and text messages four times.
I suppose we also have no verification that the passwords are no longer stored in plain text either, so changing it seems to be postponing the inevitable -- it is now a target for getting hacked again, with a delicious plain text payload as the reward for anyone doing it.
If my doctor was leaking my medical records left and right to advertisers around town, I would sue him... at some point leaking my online identity has to have some sort of repercussions behind it besides me getting online and being openly angry on the internet.
Wrote a quick command line Gmail password changer for this type of thing; if I see my username I can go ahead and start changing passwords. Hopefully I'll pound more out this weekend. http://christopherwoodall.com/gmail.py
> If my doctor was leaking my medical records left and right to advertisers around town, I would sue him... at some point leaking my online identity has to have some sort of repercussions behind it besides me getting online and being openly angry on the internet.
What would you do ? sue them? The EULA you have accepted usually forbids it, or limits the amount of damages you can claim to a few bucks. I am not a lawyer, but i doubt such an EULA would be declared void in court.
Somehow, I think this wouldn't be the case. Otherwise, doctors would be throwing EULA agreements left and right, and saving millions on malpractice insurance fees.
I've never seen a complete waiver of rights. What you typically sign is an agreement to try arbitration before (or instead of) suing in the courts. I don't believe it is possible to waive the ability to be penalized for negligence, just the venue the penalty is assessed in.
Of course, said arbiter is much less likely to give out a seven digit award than a jury is.
Here's the communication they sent. This is totally a lie - my email was in the database, and they have been only saying an issue potentially affecting them
-------
Hi SoSasta Subscriber,
Over this weekend, we've been alerted to a security issue potentially affecting subscribers of Sosasta. We wanted to let you know that the issue has been brought under control and your accounts are secure. However, as a precautionary measure, we recommend that you change your SoSasta password immediately, by visiting the SoSasta website (Sign-In using your existing password, then click on Profile followed by Change Password). If you use the same email/password combination at other websites, we recommend you change those passwords as soon as possible, too.
Please be aware that none of your financial information (Credit Card, Debit Card, NetBanking etc) has been compromised since this information is not stored on SoSasta, as per law.
If you have any concerns or find any unusual changes in your SoSasta account, please contact our Customer Support team as soon as possible at 1800 103 2111 between 9.30 a.m. and 6.30 p.m. IST, Monday to Saturday so that we can review your account.
You should know that we are working aggressively to prevent this from happening again. Sosasta takes security and privacy very seriously -- it's important to us to provide you with a safe shopping experience of the highest quality, and we will do everything possible to keep your trust. Please accept our apology for any inconvenience or concern we've caused.
scroll down ... down ... down ... there it is (gray text on black background), the crappiest example of SEO i have seen in a long long time. keyword stuffing is so 2004.
"Berlin ist als Hauptstadt der Bundesrepublik bekannt für seine Sehenswürdigkeiten und das umfassende Angebot an Freizeit-Aktivitäten. ... ... Berlin Deal ... ... Rabatten ... ... Geld zu sparen... ... Gutschein ...bla ... ... Angebote des Berlin Deals ... ... Wellness-Angeboten ... ... Restaurantgutscheinen.... ... .Freizeiterlebnisse, Events und Dienstleistungen in Berlin ... ... Shopping und Online Shop. ... ... Berlin Gutscheine ... ... "
i would have guessed that a multi billion dollar company could at least hire a decent SEO guy.
yeah, i know, but shitty SEO is not worth a separate 'submit' - also the overall theme of this thread is 'just another poor business decision / f*ck up by groupon' and this seems to fit the bill
Ok my mouth is literally a-gape at the number of database dumps indexed by Google. I guess I just never thought of searching for something so simple and now I'm floored at how often this seems to happen. How does anyone possibly allow a data dump to come anywhere near somewhere Google could index it?
Google also has to know that the file is there, before indexing it, either from a link available to Google, or from the website's sitemap, or by activating directory listing in Apache, or some other shit like that.
This is very simple. If you're using Chrome Browser, ChromeOS, or Google Toolbar, then google is using their pagerank tech ... or essentially sending the url you type into the browser to their servers for ranking purposes. If you can access it freely on the net, assume it is already indexed, even if there are no links to it.
> The Google toolbar sends information to Google for every page visited, and thereby provides a basis for computing PageRank based on the intentional surfer model.
For it to display a pagerank, it has to send the url to Google (otherwise, how is it going to know what to display the rank for?). Google can then send the crawler to that address later.
> If valid, I'd consider this an almost dangerous breach of privacy.
I don't believe they monitor who is going where. Just where people are going. Although it would be trivial for them to monitor who is going where ...
Also, an FYI, if you are logged in to Google and you're using their search engine, then they ARE monitoring you. Check out Google Web History.
I was concerned more with content indexing of URLs that are not meant to be public, to the point where that content could show in search results. Imagine my editor emails me a link to a blog article for approval before publishing. Or, as a designer, you create a draft of a web page to show to your client; and for the convenience of said client, you prefer not to have it password protected (nor take the time to set it up - you have enough to do!)
In both cases, imagine that someone loads the URL in their Chrome browser. If that action resulted in the URL being added to the googlebot's itinerary, even though no publicly visible webpage links to it, the result could be the exposure of information that we don't want. Or for the blog post example, it could even affect SEO by causing a duplicate content penalty.
Of course we can password protect the page, exclude the urls in robots.txt, etc. But there is a labor cost and inconvenience to having to do that, and there is always risk that something would slip through.
That said, what I write above is likely pure speculation; I don't know of any evidence that Google is actually doing this, and it seems unlikely to me that they would.
Also, searching on link:http://www.sosasta.com/uploaded/ doesn't show anyone linking to it. Even if the directory is there, it had to get there in the first place somehow.
Most Indian computers I've seen are standard American or British layouts. India has a lot of English speakers [1] and most computer-savvy folk, especially the kind that use Groupon will definitely know enough English to use English usernames and passwords.
See how easy this is, why complicate things unnecessarily.
---------------------
I guess the guy wouldn't have even imagined mighty google will index this & people from around will download the file, resulting in major security breach.
This is what you get when you act ignorant or plain lazy. poor guy...lol
Incidents like this make me think that if success is anything to do with talent? Even a mediocre developer wouldn't do such mistake and these people are acquired by Groupon. Then, I think, it's all about who you know ?
It appears you're putting the equal sign between developer ability and business success. Being a great developer lands you a good job with a 6-figure yearly salary. Being successful in business requires a different sort of talent.
Business "talent" is primarily about knowing what matters. There are lots of Groupon clones or other startups where founders can't do basic arithmetic on user acquisition costs or lifetime customer value, or they choose to work on scaling the backend prematurely or on solving things that will not matter unless they achieve product/market fit and scale. Recognizing priorities and working on what matters is also talent, or more precisely, a lot of hard work.
Once you have product/market fit, doing risk management is a must and nowadays it seems to be a lacking skill (look at this incident or the Dropbox story from a couple of days ago). But doing risk management is like translating your business in French: if you're big it pays off to do it but otherwise you should be more worried about not dying.
Therefore I'm not surprised when I see that people who are focused on not dying more than risk management have been more successful in reaching... "success" (managing it once you've got it is another business)
I am a young 20 something, right out of college, first time startup founder, developer and with almost zero business knowledge guy. It's hard to accept the truth you are saying, but I am learning.
Just make sure you can tie everything you do to your customer's needs. If you find yourself thinking about technology for technology's sake (e.g. "let's rewrite in Scala" or "We need a 12-tier system to manage scalability) (for you curtsy user...)), start worrying.
Fortunately, there is an easy cure: go talk to customers. Your good customers (or potential customers) will point you the right way.
It might have been good that it was indexed by Google so that the problem was found quicker. Completely agree about how can cleartext be allowed. Harder to regulate overseas, but would it be possible to have an actual law in the USA against storing passwords and other confidential in cleartext? There are various consumer protections such as food, cars, toys, and could similar things be legislated for data?
PCI isn't law, it's the product of an industry group, and is arguably more about the protection of the networks and issuers than consumers.
There is even less guidance and specific regulation pertaining to the encryption and security of banking records. The audits and regulations that are in place are more about overall controls than technological measures.
Yes, my impression is that passwords are not treated with the same seriousness as say credit card numbers, or health info. That (passwords) was actually what I was curious about, before I generalized my comment.
Obligatory post I make on these stories: Use PwdHash for Firefox and Chrome. It's very low overhead and provides and extra layer of protection from lazy programmers.
That only tackles the master password for every site issue. It does not solve the password being plaintext.
For example, Facebook has a central ID and if they don't protect the password that gets exposed, someone could use the password to withdraw money from another section of the website.
Not quite. At the moment it's virtual currency [0]. My point was that security holes increase as service increases in complexity. Especially when it's used for everything and becomes a hard lesson in SPoF for users, like the money example.
PwdHash looks great and it would be nicer if it was implemented by all browsers. To take the idea further, what if the HTML5 standard for input type=password automatically did the hashing before forms are submitted? On any form submission, browsers would hash like PwdHash by using the current domain. There would also be no need to use a prefix like PwdHash. Those are some quick thoughts and I think there's better ideas that can be implemented, that don't require work for consumers. Won't protect against things like weak passwords, but even a little contributes to security.
I use PasswordMaker which has support for pretty much every browser and uses the current url for hashing (and you can always override the default salt). http://passwordmaker.org/
Holy cow. This thing is even better than PwdHash (ability to avoid special chars in particular, and multiple platforms supported, and it's actually being maintained). Thanks!
> On any form submission, browsers would hash like PwdHash by using the current domain.
Nitpick: works great until you move domains, or try to log in from another subdomain, or use a redirect in your /etc/hosts file, etc., etc.
Assuming that the submitted hash would (should!) be salted and hashed again server-side anyway, simply running it through bcrypt would be enough, I think.
An optional attribute could be added, too: <input type="password" salt="sosasta" />. If we wanted to go further, the salt could be a randomly generated nonce that would be submitted as another field; POST['password'] = 'whatever', POST['password_salt'] = 'sosasta'
I don't think a nonce would work, because the server wouldn't be able to verify whether the hashed value you sent was correct or not. The whole point is to never send your 'real' pwd to the site, because they're going to do something idiotic like store it in plaintext, and then you have to change it everywhere.
Heads outta roll for this one. The dev, the supervisor, his supervisor. Probably all the way up to VP.
It's a stupid, boneheaded mistake, but one of those that could only be made in an environment where security is extremely lax. Easiest way to fix the environment here is to just fire everyone involved.
Maybe Google should start working with security firm so that once their bots crawled on a leaked database they will notify the website owner immediately.
How would Google do it with an algorithm to tell whether a database is leaked or not? Get emails from the firm to assess it? Maybe a honeypot email?
In that case, it seems far more easier for developers to put in honeypot emails in the databases and constantly query search engines hourly when those become available.
That is assuming database gets released, let along exposed for indexing.
I can't think of a reason why Google would care... I certainly can't think of a reason why Google would care enough to spend money on staff/research in order to get that type of content out of the index.
If you don't want something indexed, don't put it on the web. And sure as hell don't link to it.
True, if you are incompetent enough to expose your most sensitive data on the internet yourself, why do you expect others to come to your aid. Even if Google does not index it, what is stopping other search engines from indexing or hackers to get access to it directly. There are lot of tools which will automatically index all the content of a website with the click of a button. So I think it is best to put the onus on the website collecting the user data to protect it. If they cannot, then maybe they should just use some third party authentication and minimize the amount of sensitive data that they need to keep on their servers.
If Companies itself ready for compromising there email id and password then who can protect them. Hacker's just shown there mistakes done to the people.
Otherwise a small child knows well how to hide his password from the other people.
I am not normally in favor of legislation, but I'd be okay with a fine for US-based companies that leak and expose this kind of data. Specifically a harsher fine for cleartext or anything less than bcrypt.
I worry, though, that it would end up making things more difficult for developers while not improving things for the end users - much like the European/Dutch cookie law.
This is a lie. Neither I nor my brother have heard from them. Keep in mind that this happened on Friday and it's already Tuesday here. In the meantime, I have been spammed about deals that I don't care about through e-mail and text messages four times.