Live data from Hacker News

Microsoft Store hacked in India, passwords stored in plain text

engadget.com

31–40 of 41 posts

Re: Microsoft Store hacked in India, passwords stored in plain text

#32
post #7

Earlier quoted context omitted.

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.

Re: Microsoft Store hacked in India, passwords stored in plain text

#34
post #7

Earlier quoted context omitted.

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 ;-)

Re: Microsoft Store hacked in India, passwords stored in plain text

#35
post #4

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

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

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

Re: Microsoft Store hacked in India, passwords stored in plain text

#36
post #17

Earlier quoted context omitted.

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

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.

[deleted]

Re: Microsoft Store hacked in India, passwords stored in plain text

#37
post #17

Earlier quoted context omitted.

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

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 would like to add that MediaWiki does this. Here is the DB schema: http://upload.wikimedia.org/wikipedia/commons/2/2c/Mediawiki...

Re: Microsoft Store hacked in India, passwords stored in plain text

#38
post #16

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.

Re: Microsoft Store hacked in India, passwords stored in plain text

#39

Earlier quoted context omitted.

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

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.

Re: Microsoft Store hacked in India, passwords stored in plain text

#40
post #20

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 pas…

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.

Post reply on HN