Skip to content

Instantly share code, notes, and snippets.

Created March 8, 2012 15:15
Show Gist options
  • Save jashkenas/2001456 to your computer and use it in GitHub Desktop.
Save jashkenas/2001456 to your computer and use it in GitHub Desktop.
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
* I'm very sorry.
* Email me at 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
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
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.
Copy link

Baggz commented Mar 8, 2012

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

Copy link

dogeared commented Mar 8, 2012

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 34sm4054142anu.6

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

Anyone else see this?

Copy link

dogeared commented Mar 8, 2012

Looks like it's fixed now, FYI

Copy link

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

Copy link

@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: .. Making the system OPEN to all, and the KEY secret, is the most secure way to secure anything.

Copy link

djbender commented Mar 8, 2012

Bcrypt it. now.

Copy link

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

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

Copy link

Use bcrypt

Copy link

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

Copy link

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

Copy link

mxey commented Mar 8, 2012

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

Copy link

ded commented Mar 8, 2012

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment