|Security Alert - Please reset your npm registry account|
|The security of the npm registry has just been upgraded. This corrects a known|
|flaw which led to the leakage of the password_sha and salt fields. The good|
|news is that the leak is plugged. The bad news is that it existed for quite a|
|* Your password wasn't leaked, but the hash was. Still not great.|
|* It's fixed now.|
|* Reset your npm account at http://admin.npmjs.org/reset|
|* I'm very sorry.|
|* Email me at firstname.lastname@example.org if you have questions or would like to chew me out.|
|You have every right to be upset.|
|To do login, npm uses the /_users database in couchdb. By default, CouchDB|
|prior to version 1.2.0 makes this database world-readable.|
|Your password wasn't leaked. However, the password_sha hash and the salt was.|
|This means that someone with lots of CPU power at their disposal could|
|eventually crack it. If your password is relatively short, then less CPU power|
|would be needed. If your password is a single dictionary word, then even less.|
|What We Did About It|
|The npm registry has been upgraded to Couchdb 1.2.|
|In order to facilitate the use cases where npm needs to read a user's public|
|info, the non-sensitive pieces of the user record are being copied to a|
|/public_users database, and the rewrites have been changed to point to the|
|This means that the npm client continues to work without changes, and that|
|the problem is fixed at the source, rather than relying on adding additional|
|layers. Any downstream replicants of the registry will continue to work with|
|their (exposed) _users databases without any changes.|
|Why Wasn't This Disclosed Sooner|
|It seemed wise to fix the exposure before telling a few thousand people about|
|it. Jason Smith and I deployed the fixes on Monday 2012-03-05. We waited a|
|few days to make sure that it didn't cause any additional problems, and to test|
|things out. So far, it looks solid.|
|I'm very thankful to the handful of people who reported this to me discretely|
|rather than create more drama than necessary.|
|What You Should Do|
|Here are the options:|
|Do nothing. Least secure, most convenient. Probably not enough.|
|If you used a very strong password (eg, some string at least 20 characters or|
|so) for your npm account, then this might be ok. If it was something short,|
|or something you use in multiple places, then please read on.|
|Reset your npm password at http://admin.npmjs.org/reset|
|It's a 3-step process. The thing emails you a link. You click the link. Then|
|you remove the `_auth` line from your ~/.npmrc file, and run `npm adduser`|
|to re-create your account. If you only used the password for npm, and not for|
|anything else, then you're done.|
|If you have an old account containing capital letters or spaces in the|
|username, then you'll need to create a lowercase url-safe version and add it|
|to your packages. Ping me on IRC and I'll help out. (There are only a few of|
|Reset/change the password of any service that has the same password.|
|Because your username and email address are part of the public npm registry|
|data, someone could take the exposed password and try it on facebook, twitter,|
|foursquare, HSBC, Bank of America, and so on. This would not be good.|
|Once again, I'm very sorry about the exposure, and the inconvenience it causes|
|for you. You have a right to be upset. Feel free to email me with your gripes|
|and complaints, as well as any additional questions you might have, or if you|
|have any problems resetting your password.|
@mxey: from the CouchDB docs you can see that it's not a simple hashing: sha1(password + salt) where salt is a 128 bit UUID. It is rainbow table proof, but it doesn't provide any key stretching method as bcrypt does. sha1 bothers me more than the lack of stretching though.
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
And what do you do when you get
npm http 409 https://registry.npmjs.org/-/user/org.couchdb.user:ejeklint/-rev/4-ca32997ccae671d4dbab03d5e8a088b9
when doing as told? :-)
@mxey that would in no way make things more secure. http://security.stackexchange.com/questions/5586/why-do-people-think-that-this-is-bad-way-to-hash-passwords
When I go to do the reset, I get a message saying:
This is probably because we have misconfigured something on the backend, please try again later.
Anyone else see this?
@jcolebrand: a lot of people that comment that StackExchange question don't understand the concept of a rainbow table in relation to a password salt vs key stretching, therefore that example is really, I mean really, bad. Besides, any sane person that designs a hashing scheme won't use something like: repeat X times foo = hash(foo). It's time for people to use proven hashing schemes instead of making their own though.
@SaltwaterC ~ Wait, what? Did you read the whole discussion (because part of the conversation is from people who don't know what they're doing)? Do you mean that the SECURITY EXPERTS don't know what they're talking about? I'm sorry sir, but you are sadly mistaken.
Repeated hashing on SHA-1 (or any other scheme) doesn't make things "more secure".
Additionally, who's talking about making their own hashing scheme? It's been said many times (and Bruce Schneier has said it himself many times) and is even codified here: http://en.wikipedia.org/wiki/Kerckhoffs%27_principle .. Making the system OPEN to all, and the KEY secret, is the most secure way to secure anything.
@jcolebrand: do you understand any sentence from what I say?
I'll add this last bit:
@SaltwaterC You said that the post I linked to was incorrect, when I was replying to another user who suggested that this was an action that would make the codebase more secure. You are the one who said I was wrong, when I'm not wrong. Therefore I am against you, because I know that what I linked to is accurate. Doing more hashes (as was suggested at the top of this thread, and as asked in that question) does not make anything "more secure" (note also that this is not the same as key stretching).
The thread I linked to is about security. Changing your passwords (as advocated above) because the hashes got released, is security. Key stretching, SHA-1, MD5, etc ~ those are security. Which part is obscurity? The fact that key-stretching adds an artificial delay to the process, yes, that's obscurity, but the fact that the process is well known doesn't change the secure nature of any of this ~ that is the very nature of my message.
@jcolebrand: "hashing repeatedly a few 1000 times" is bit vague as it doesn't describe the method, so maybe you jumped the conclusion. The OP we're arguing about also proposes bcrypt, therefore if the OP took the time to read about bcrypt, maybe that quote isn't as stupid as it looks if you think a little bit about it. UNIX crypt SHA2 schemes iterate the hashing algo 5000 times by default. That means either SHA256 or SHA512. This doesn't mean that it is a simple iteration which your link implies.