Groupon leaks entire Indian user database
risky.biz
risky.biz
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.
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.
Yep, that'll do it ;)
ADDENDUM. Speak of the devil (another HN story): http://www.consumeraffairs.com/news04/2011/06/cloud-site-dro...
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.
Of course, said arbiter is much less likely to give out a seven digit award than a jury is.
Just not seriously enough to encrypt passwords.
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.
Sincerely, SoSasta Customer Support
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.
--------------------- First,Take the db dump, for backups/setting up another server etc.
$ mysqldump -u <user> -p <password> <db name> > xyz.sql
Now, lets move db dump file to webroot, I hate SSH,FTP,RSYNC -- too complicated for me. I like clicking hyperlinks. KISS FTW!
I guess nobody will notice that file is present here. How can they know, I won't tell them!
$ mv xyz.sql public_html/uploaded/users
now, I can download it simply by going to
http://www.sosasta.com/uploaded/users/xyz.sql
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
Or, in general case[1], when 'industry standard' tools are PITA to use. Simpler solutions are always preferred, for better or worse.
[1] I'm not defending here the person that caused the SoSasta breach.
EDIT: Formatting.
Let me just put this sql dump in the web root for a couple hours to copy over to the test server.
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.
The database dump is here: http://www.secretserver.com/database.sql.gz
Don't tell anyone.
Google honours robots.txt, X-Robots headers etc but everything else is fair game.
And, as the others state, if it's not robots.txt denied then why not add it to the public index?
http://en.wikipedia.org/wiki/PageRank#The_intentional_surfer...
> 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.
[1] http://en.wikipedia.org/wiki/List_of_countries_by_English-sp...
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)
Fortunately, there is an easy cure: go talk to customers. Your good customers (or potential customers) will point you the right way.
More: https://secure.wikimedia.org/wikipedia/en/wiki/Information_p...
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.
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.
This extension is helpful because people reuse passwords: a leaked password cannot be used to causes damage on other sites.
Obviously, I agree that sites shouldn't store passwords in plaintext, but good luck enforcing that.
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'
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.
If you don't want something indexed, don't put it on the web. And sure as hell don't link to it.
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 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.