Hacker News new | comments | show | ask | jobs | submit login
Microsoft Store hacked in India, passwords stored in plain text (engadget.com)
109 points by zalthor 2132 days ago | hide | past | web | favorite | 35 comments

Disclaimer: I used to work for Microsoft

I think Microsoft needs to take a ton of heat for this one.

a) They outsource something running on a Microsoft domain, with the Microsoft logo, etc to an external entity, something customers wouldn't know about unless they read the ToU

b) That external entity wasn't held to even the most basic of security precautions - no MSFT online property would even be allowed to store passwords (that's the job for the LiveID guys) let alone do it in cleartext.

This is the sort of move for which people should get fired over.

This reminds me of the spate of hacks on Sony's sites. I wonder how many more MS sites are operated by third parties, and exactly how vulnerable are our personal information?

Let the heads roll.

Whenever you outsource make sure you watch the code very, very carefully. At least 90% of the people I meet (at least here in Bangalore) would store passwords in clear text and not know why this is a bad thing.

Microsoft fully deserves the blame here, for not asking basic questions. Besides, the rest of the code is likely to be smelly too if the entire team failed to notice the issue.

Microsoft definitely need to take the burn on this one.

You don't even need to look at the code to find out the passwords are stored in plain text. A quick tour through the database during testing would tell you everything you need to know here.

This is nothing more than laziness and ignorance.

So I've worked in an ASP.net environment and I generally hated it, but ...

The overall framework had a lot of features and examples abounded (http://msdn.microsoft.com/en-us/library/ff648341.aspx)[2005]. It's very difficult to imagine a company <<skirting around>> the many ASP.net examples in order to store passwords in plaintext. It's astounding to see that Microsoft itself did so... Seems that it says that examples don't actually abound or that the system is so complex that not even Microsoft could understand it.

More likely, Microsoft hired a low-cost contractor to build/manage their Indian site and suffered. Another sign that MS has lost touch.

EDIT: another commenter writes "The store isn't actually run by microsoft, but rather Quasar Media.", so Microsoft outsourced their site...

A long time ago (10+ years), Microsoft cleaned up all of their sample code for security purposes to avoid people cut and pasting insecure code to stop exactly this type of boneheadedness.

The store isn't actually run by microsoft, but rather Quasar Media. It tarnishes Microsoft's name, but it isn't their fault.


Was it the Microsoft store or not? If it was an MS store, then it's their fault. The store was branded with the MS brand in order to convey to consumers that the store could be trusted. That Microsoft contracted hosting/development out to a crappy firm is Microsoft's fault not the consumer-who-trusted-their-brand's fault. Users trusted that an Microsoft-branded domain would be kind. Fail.

Not suprising, a few years ago, I forgot my password for the Ted Ed South Africa website. I phoned in to reset, and had my password read back to me over the phone.

Incorrect report, there was no image with a Guy Fawkes mask. This is the actual image that had appeared on the site


Some self-promoting guy seems to have sent Endgadget that screenshot.

I love how the fields are prefixed with acronyms for the table name.

Curious, is there a good reason to do this ever?

I guess you could say that then you never have to qualify the column name in the query (as they're unique across the system). It's a pretty crummy reason to do it though.

More likely it's just that someone decided that was how they were going to do it one day and it stuck.

I worked on a system where all tables were prefixed with "tbl_" - even when they were often views and not tables at all....

Gotta love cargo cult Hungarian notation.

Just to be clear, not all Hungarians endorse this notation ;-)

If you are using PHP without a framework and mysql_array_assoc, there can be collisions / inconsistencies / problems in joined columns that have the same name. I've run into it a few times. Most decent systems don't choke in that case, but there are cases where it's simply easier to prefix column names instead of writing AS everywhere. If you're working with really long SQL queries generally it can also help make things more explicit.

I don't do this usually but I have run into a couple of occasions where it would have helped out.

When you do a SELECT * and with a join or two, you get the chance of field name conflicts which can cause logic errors. You either have to alias the conflicting fields, specify each field you want on the select, or prefix field names so they never conflict.

I've used this myself in the dim and distant past (there is still code in my area of responsibility that shows signs of it).

I find the much better method is to be strict about table names and aliases:

1: Always specify the table name with field names. Even if there is only one table in the query (if the query changes later to draw in data from another table, you don't have to go back and add the table references if they are already there). As well as avoiding name conflicts which will raise errors, it removes certain silent fails that are possible with correlated sub-queries when you don't explicitly note the intended scope by naming the object a column should be found on.

2: Always specify a short but meaningful alias for every object referenced in the query/view (such as "kpi_fact_definition AS kfd"). It makes the code more readable when every column reference has "<table>." prefixed.

2b: All aliases should be unique within the query/view even if the same object is referenced more than once where the scope of each reference means the names/aliases would not conflict. Also try to avoid using aliases that are visually similar (visually similar aliases can lead to typing errors being able to hide in plain view).

3: Make sure that all tables/views have meaningful names, even if they means them looking overly long. You are going to give them short aliases when you use them anyway.

I would like to add that MediaWiki does this. Here is the DB schema: http://upload.wikimedia.org/wikipedia/commons/2/2c/Mediawiki...

If your database has a very limited query language that doesn't allow you to specify tables for fields in queries, this may prevent name clashes.

I can't imagine anyone having this problem after the early 90's...

They were probably using a C compiler from the 70s that puts all struct members in a global namespace.

The effort it would require to do something that absurd is astonishing.

It was supposed to be funny, but I'm afraid it was too subtle.

Doesn't ycombinator still store passwords in plain text?

Or has that been fixed now?

The version of news.arc last shipped from arclanguage.org hashes the passwords (I'm not sure what exactly it uses), and that's very old. pg and rtm might've changed it since. I highly doubt that HN ever stored passwords plain text, especially considering who rtm is.

Guess what, they seem to be managing some of Nokia's and Panasonic's resources as well.

Off you go Quasar Media, you're doomed.

Here's the actual blogpost from the one who claims to be the hacker


Can someone explain why the screenshot contained text that looks Chinese.

according to the hacked page, it's obviously a Chinese Hacker




Note from the blog page

> 不解释,撸过~

actually means "No comment, fap fap fap"

got the origin links_source 哈哈。葫擼娃

I think engadget just blurred out the passwords there.

No, if you look at the characters in the UI.

Still, clearly the answer is that's a hacker's computer. Just because its an India store doesn't mean the hacker is Indian.

Some engadget reader sent the content of the file with a screenshot. Maybe a hacker's computer not necessarily the hacker's computer. Just to be clear.

Yes that cleared it up, thanks.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact