Doesn't ycombinator still store passwords in plain text?
Or has that been fixed now?
Microsoft Store hacked in India, passwords stored in plain text
21–30 of 41 posts
Re: Microsoft Store hacked in India, passwords stored in plain text
#22Doesn'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.
Re: Microsoft Store hacked in India, passwords stored in plain text
#23Can someone explain why the screenshot contained text that looks Chinese.
according to the hacked page, it's obviously a Chinese Hacker http://wpsauce.com/wp-content/uploads/2012/02/microsoftstore... http://ps.s.blog.163.com/ http://ps.s.blog.163.com/blog/static/89878892201211132353615... Note from the blog page > 不解释，撸过~ actually means "No comment, fap fap fap"
[deleted]
Re: Microsoft Store hacked in India, passwords stored in plain text
#24Re: Microsoft Store hacked in India, passwords stored in plain text
#25Can someone explain why the screenshot contained text that looks Chinese.
I think engadget just blurred out the passwords there.
Here is the image that shows the passwords (email IDs are still hidden though).
http://img7.ph.126.net/wWJQXBUb5HzfZKPphMH9iA==/288286671148...
I'm pretty impressed by their choice of passwords, except for one Aseem Bansal who has aseembansal as his password.
And here's the hacker's blogpost that has some screenshots
http://ps.s.blog.163.com/blog/static/89878892201211132353615...
Re: Microsoft Store hacked in India, passwords stored in plain text
#26Guess 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
http://ps.s.blog.163.com/blog/static/89878892201211132353615...
Re: Microsoft Store hacked in India, passwords stored in plain text
#27Can someone explain why the screenshot contained text that looks Chinese.
according to the hacked page, it's obviously a Chinese Hacker http://wpsauce.com/wp-content/uploads/2012/02/microsoftstore... http://ps.s.blog.163.com/ http://ps.s.blog.163.com/blog/static/89878892201211132353615... Note from the blog page > 不解释，撸过~ actually means "No comment, fap fap fap"
got the origin links_source
哈哈。葫擼娃
Re: Microsoft Store hacked in India, passwords stored in plain text
#28Whenever 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.
so you went around asking people how they store passwords, did you? Load of crap!!!
Re: Microsoft Store hacked in India, passwords stored in plain text
#29Incorrect 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.
Re: Microsoft Store hacked in India, passwords stored in plain text
#30Earlier 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'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 "." 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.