npm-password-leak.txt

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

tl;dr

* 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 i@izs.me if you have questions or would like to chew me out. 
You have every right to be upset.

Details

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

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

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.

--
isaacs i@izs.me

password_sha sounds like you use simple hashing to protect the password. Have you thought about using something more secure like hashing repeatedly a few 1000 times or using bcrypt?

@mxey: that's a question for @isaacs. Jeremy just pasted an email into a gist. Or, at least, that's what I assume, considering I received this full text in an email from @isaacs last night.

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

And what do you do when you get

npm http 409 https://registry.npmjs.org/-/user/org.couchdb.user:ejeklint/-rev/4-ca32997ccae671d4dbab03d5e8a088b9
npm ERR! Error: conflict Document update conflict.: -/user/org.couchdb.user:ejeklint/-rev/4-ca32997ccae671d4dbab03d5e8a088b9

when doing as told? :-)

The reset emails are apparently backed up by a couple hours, so I don't think there's anything you can do at the moment. I'm seeing the same error.

2012
not using bcrypt

ishygddt

@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

Error: 550 5.4.5 Daily sending quota exceeded. e45sm6225848yhk.2

When I go to do the reset, I get a message saying:

User Reset
There was a problem sending you an email:

Error: 535-5.7.1 Please log in with your web browser and then try again. Learn more at
535 5.7.1 https://support.google.com/mail/bin/answer.py?answer=78754 34sm4054142anu.6

This is probably because we have misconfigured something on the backend, please try again later.

Anyone else see this?

Looks like it's fixed now, FYI

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

Bcrypt it. now.

@jcolebrand: do you understand any sentence from what I say?

1. That question is about iterating md5 20 times. That's an example of DYI hashing scheme done wrong. Which in the first place was a reply against somebody talking about iterations without giving out too much info about the nature of those "iterations".
2. The key stretching does exactly that, but as I said, it is not a simple repetition of a hashing algo which is plain stupid. Food for thought: scrypt, bcrypt.
3. I said exactly the same thing about using proven hashing schemes. Stuff that's out there in the open. The key is only known by the user. I didn't exactly use those words, but hopefully, other people can read between the lines. You're disagreeing with me upon something we both share the same view.

I'll add this last bit:

4. This is not security, is obscurity. Stuff that's unfeasible for an attacker to compute by using raw CPU power.

Use bcrypt

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

@SaltwaterC Yes, I was referring to a glibc-like scheme, although I am not familiar with its details.

..............dammit..... i've got like 30 modules and a decent npm name. boo