-
-
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 | |
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 |
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
@jcolebrand: do you understand any sentence from what I say?
I'll add this last bit: