Chinese Developer Forum Leaks 6 Million User Credentials 102
gzipped_tar writes "The 'Chinese Software Developer Network' (CSDN), operated by Bailian Midami Digital Technology Co., Ltd., is one of the largest networks of software developers in China. A text file with 6 million CSDN user credentials including user names, password, emails, all in clear text, got leaked to the Internet. The CSDN has issued a letter of apology to its users. In the letter, it is explained that passwords created before April 2009 had been stored in plain text, while later passwords were encrypted. Users created between September 2010 and January 2011 may still suffer from email address leaks. A summary of the most frequent passwords without the corresponding usernames is available at GitHub. Somewhat surprisingly, the cryptic sounding password 'dearbook' ranks 4th with 46053 accounts using it."
Interesting... (Score:1)
'dearbook'? (Score:2)
What does 'dearbook' mean something to the chinese? It sounds like nonsense to a native English speaker.
Clear text passwords - idiots.
Re: (Score:1)
Do you really think that is true? Especially in the technical world? That US people have no idea that there are other cultures in the world? Pfftt ... BTW ... do YOU know what a dearbook is? Show me YOUR lack of ignorance! And do it without searching the Internet :)
I find it "surprising" that people continue to stereotype all US people as ignorant of other cultures.
Re: (Score:2)
Especially in the technical world, yes. I was reading an interview with Linus where he says that most people use English when talking about technical matters even if they both have the same first language.
Re: (Score:3, Insightful)
But that doesn't mean people are ignorant of cultures. English is simply a good language for technical matters, for a large number of reasons. Being the de facto standard is only the most obvious.
Also, I should point out the British invented English, not the US, and they spread it around the world, so I'm really not sure what your point here is. Point of fact, the US probably has more variety of culture than any other nation in the world.
Re: (Score:1)
Actually, I think the English invented their language. And, that predated Great Britain by a couple of years, at least.
Re: (Score:2)
Sort of. It and "Lowland Scots" evolved alongside eachother with the same root. They diverged over a couple of centuries, but they are still very similar, and it's quite comprehensible to a native English speaker.
Re: (Score:2)
It doesn't necessarily, but it does mean that many people can speak to others online assuming they're American just because they speak English. People assume I'm American all the time..
Re:some thing to do with dearleader? (Score:5, Informative)
Re: (Score:1)
Re: (Score:3)
1 2 3 4 5 6 7 8 9 0 .
q w e r t y u i o p
a s d f g h j k l ;
z x c v b n m ,
Re: (Score:2, Insightful)
Re:'dearbook'? (Score:5, Informative)
dearbook.com.cn is a chinese online technical book retailer owned by CSDN.
Re: (Score:1)
dearbook.com.cn is a chinese online technical book retailer owned by CSDN.
The first answer that doesn't take the piss. Thanks.
Re: (Score:1)
It's the Chinese' answer to Amazon (dearbook.com.cn). Probably devs for said site.
Re: (Score:2)
All 47000?
Do excuse me for this. Ahem. "lol".
Re: (Score:3)
Re: (Score:3)
Re: (Score:3)
Could be cultural but my money is on several thousand spammer-created accounts using the same password.
Re: (Score:2)
Ok, I'm wrong about this- most likely the bookstore...
Re: (Score:3)
Re: (Score:2)
A work friend's response:
----------------
From what I guess, (just for fun)
In English,
1."Oh Dear"=="Oh God"
divide "Oh" on both sides=> dear==god
thus "dearbook" =="godbook"
In Chinese,
"tian"=="god"
"shu"=="book"
"tian shu" literally means a book that only God can read. It is basically a book has nothing but blank pages. :)
Re:How many people here on slashdot (Score:5, Funny)
Shit! Now I have to change it. I'll just add a 5.
Re: (Score:2)
"Who cares" level of password (Score:4, Insightful)
They all seem to be the sort of password I'd type in for an account that I really don't care about, and am only creating because it's mandatory.
Does the site offer/store anything that would be worth the effort of creating a password worth caring about?
Re: (Score:2)
Does the site offer/store anything that would be worth the effort of creating a password worth caring about?
As a CSDN user, I'd say : No.
Still, it doesn't prevent millions of users, who are too 'busy' to even bother use a dummy password, from actually using their main passwords (web banking, email etc.) on the AD riddled forum.
Before April 2009 (Score:5, Insightful)
UPDATE users SET password = SHA1(password) WHERE created_at
There. Did it for you. Won't prevent everything getting stolen, but at least you don't give away any more passwords reusable on other websites.
I mean... seriously?? So you have to check in your code if an account has been created before and after 04/2009, and do different actions to check their credentials upon that? Yuuuck.
Re: before April 2009 (Score:3)
UPDATE users SET password = SHA1(password) WHERE created_at <= '2009-04-01';
I hate angular brackets in HTML.
Re:Before April 2009 (Score:5, Informative)
Mediawiki is (re: was) like that. When it changes password schemes it detects which version the pw is stored in, authenticates using that (older) method and then upgrades you to the new format.
Re: (Score:1)
This is because the old format was ALSO hashed (but not salted). You can't do the update query above unless you have the plaintext.
Re: (Score:2)
If it only updates after login and you don't login any more because you got fed up with wiki*...
Re:Before April 2009 (Score:4, Insightful)
That's cool, but there should be salting. http://en.wikipedia.org/wiki/Salt_(cryptography) [wikipedia.org]
Re: (Score:1)
Re: (Score:2)
I live in China, the problem is not that the technicians do not know how to do this (well many are shockingly incompetent; if I described my desktop XP install, here in my office, you would blanch); the problem is that the decisions are not made by the people doing the work. The decisions about what needs to be done are made by leaders.
The leaders do not need to hear ideas from below, if the people below had any worthy ideas then they would be leaders. They give orders and the orders are acted on; or not de
I've never understood clear text passwords (Score:2, Insightful)
It's sooooo easy to md5 a password before doing anything with it. md5 it in javascript and never bother collecting the clear text, is it the most secure ever? probably not. Is it a billion times better than cleartext and unbelievably easy? Yes.
Re:I've never understood clear text passwords (Score:5, Insightful)
If the MD5 is all that gets sent, it is the password. If someone gets the MD5 hashes they can log in by hacking the Javascript to send the MD5 without ever having the original password.
Re: (Score:2)
What you say is true, but one benefit of doing an MD5 before it's sent is that one can't infer other passwords from a MD5 hash. A person might use passwords that follow a similar pattern that can be deduced by looking at cleartext, but not from hashes. For example, passwords a person might use could be "mypassword@slashdot", and "mypassword@sourceforge", one could probably guess their Facebook password.
Added salt helps even further.
The conclusion is that the authenticator should never receive the client's
Re:I've never understood clear text passwords (Score:4, Insightful)
There's nothing wrong with hashing your own password so that someone can't infer "mypassword@sourceforge" from "mypassword@slashdot", but you can't trust a client-side hash function any more than you can trust the server-side authentication, unless it's your client-side hash function.
There's no benefit in designing a login form that hashes the password before it's sent, as long as the form is using SSL. Furthermore, there's no backward-compatibility for people who have Javascript disabled. They can't log in.
Re: (Score:2)
You don't have to trust the client-side hashing function, as ordinarily you're not expecting it to be implemented on top of ordinary security. It's simply a bonus level of security a site can provide, even in the case of SSL transport, in case the receiver is compromised. In other words, it's possible that one component of the authentication process that handles the client-side-generated string (either a hash or cleartext password) is compromised, but not the authentication prompter itself. In this sort
Re: (Score:2)
You don't have to trust the client-side hashing function, as ordinarily you're not expecting it to be implemented on top of ordinary security. It's simply a bonus level of security a site can provide
From the user's perspective, the same benefits would be obtained equally well by simply not re-using passwords. From the web designer's perspective, there's no benefit to hashing on the client vs. on the server.
even in the case of SSL transport, in case the receiver is compromised
The hash is still the password, so if the receiver is compromised, you get the password.
If the protocol enforces hashing on the client-side before sending, you don't have to worry about trusting the client-side or javascript being disabled.
Maybe you have confused hashing with encryption.
Re: (Score:2)
How about a browser plugin that causes every password text box to automatically hash its contents before submitting the form? Something like this:
User enters password in password field. Browser consults a salt database, keyed by hostname. If entry for this host is not found, adds one, and generates a random salt. Otherwise, uses previously generated salt. The browser then concatenates the password in the input field with the salt. Hashes the result. Represents in base64. The result of all this is what is ac
Re: (Score:2)
That's why I said there's nothing wrong with hashing your own passwords. However, in practice, just about every web site has its own quirky rules about what can or can't be used as a password, which makes it hard to use any single system for all of them.
Re: (Score:2)
If I understood what you meant; how do I log in from another computer?
Re: (Score:1)
If I understood what you meant; how do I log in from another computer?
Well, you'd need to install the plug-in on any browser you'd want to use, which I admit is a drawback. But the salt DB could easily be put out in the cloud somewhere. The hashes themselves aren't sensitive information.
Re: (Score:1)
Re: (Score:2)
User enters password in password field. Browser consults a salt database, keyed by hostname. If entry for this host is not found, adds one, and generates a random salt. Otherwise, uses previously generated salt. The browser then concatenates the password in the input field with the salt. Hashes the result. Represents in base64. The result of all this is what is actually submitted to the form.
I guess you can say goodbye to federated authentication schemes like OpenLogin.
Re: (Score:1)
there's an easy way to fix this kind of flaws: browser could send md5(password) but the db could store md5(md5(password))
Re: (Score:2)
No. Perhaps I should try to explain it again, very carefully. See if you can follow this.
If it's hashed on the client side, either it is or it isn't also hashed on the server side. Consider these scenarios separately:
First, assuming it's only hashed once, on the client side. That hash is transmitted and stored on the server. If someone dumps the database and gets those hashes, they don't need the original password: hack the client-side to just send the correct hash without needing the original password to c
Re: (Score:2, Informative)
It's sooooo easy to md5 a password before doing anything with it. md5 it in javascript and never bother collecting the clear text, is it the most secure ever? probably not. Is it a billion times better than cleartext and unbelievably easy? Yes.
Actually, doing MD5 on a client side script is severe no-no if it were the only form of authentication. A hacker could simply run a script running through all 16^32 possiblities of the MD5 hash instead of the almost infinite possiblities of the original password. Doing a client side MD5 actually weakens many passwords instead of strenthening them. You're left with something around an 18 character alpha-numeric-symbol password - no matter how long or difficult your original password was.
Re: (Score:3)
Do you have any idea how many that is?
16^32 = 3.4x10^38
If they could try 1M hashes per second, that would take over 10^25 years...
Re: (Score:2)
Doing it like you describe, it is effectively a cleartext password, albeit a different one than the user typed.
That's the stupidest password I've ever heard! (Score:1, Flamebait)
The kind of thing an idiot would have on his luggage!
What... (Score:2)
After looking at port scans this morning, I have one thing to say: what goes around comes around. I have a hard time thinking such incompetence as would lead to so many exploited machines is possible without just a little bit of malice.
Storing cleartext passwords is asking for trouble. (Score:2)
I'm looking at you, Mailman... http://www.list.org/ [list.org]
18th password? (Score:2)
I understand where a lot of the passwords come form but what is the basis for the 18th on the list "xiazhili" What does it mean? I doesn't line up with anything I can figure out like the others
Re: (Score:2)
The Chines language is made of thousands of symbols and there is a translation table to map those symbols to the 26 western characters. "xiazhili" might be chinese for 'swordfish'.
Re: (Score:2)
My favorites are line 82 ("!@", with 1006 accounts using it), and line 94 (empty string, with 863 accounts).
So in addition to storing passwords in clear text, they also have (had?) no password requirements at all.
And I bet some of the people there are the same people hacking into our critical infrastructure. What does that say about us?
Re: (Score:1)
... for new malware attack vector (Score:1)
password swiping (Score:1)
Re: (Score:1)
Chinese number combos (Score:1)