Hacker News new | comments | show | ask | jobs | submit login
npm (Node's package manager) leaks all user password hashes and salts (github.com)
151 points by jashkenas 1636 days ago | hide | past | web | 79 comments | favorite



The important sentence here:

    > By default, CouchDB prior to version 1.2.0 
    > makes [the /_users] database world-readable.
Note that the current stable version of CouchDB is 1.1.1.

I assume that "world-readable" in this case also means world-readable over HTTP, if your Couch server isn't firewalled.

Update: If you've already filled out npm's "reset password" form, but haven't received an email yet, @isaacs says that the email bot might be backlogged by a couple hours.


The e-mail heavily implies that the security breach was CouchDB's fault instead of those who were administering that Couch server.

Deliberate passing the buck or accidental bad choice of words?


I think more of a serious gut check for anyone who's deliberately exposing a CouchDB server to the web because it contains all or mostly public data.


My bad, just realized you aren't e-mail writer or npm admin. Thrown off by gist author.

Deliberately exposing anything to the web should come with lots of... wait for it... deliberation. The npm guy is a core community member; this incident shows a lot of sloppiness and doesn't inspire faith.


by default CouchDB gives everyone in the world admin access to your instance, it also doesnt listen on an external interface.

There isnt any confusion over 'sensible defaults' because sensible defaults dont really exist, the way people use CouchDB is very varied, if you are going to expose any data to the world you need to know what that entails, in this case I believe it was done to help people run their own npm instance and couch introduced new functionality in order to handle that case in a more secure way.

tl;dr I dont believe this is a couch issue in the slightest, purely an issue with how npm was built


by default CouchDB gives everyone in the world admin access to your instance

tl;dr I dont believe this is a couch issue in the slightest

That seems like a slightly generous interpretation...



listening on the local device and having no UAC seems pretty standard to me.

If you want to expose anything, you have to do it very explicitly and as linked there are warnings and advice about doing so.


Process security is very common even when the process listens only on a socket.


I'm wondering what you mean here when you say "on the local device". Are you implying that it is guaranteed that the local device is not exposed? I don't see why you would have to explicitly expose something. The entire instance is exposed by default.


it listens on 127.0.0.1, not not on an external interface, it is not exposed by default


But that has nothing to do with the instance access control or the database access. Changing the listening interface isn't going to magically fix the default security setup.


Also worth noting: By default, CouchDB is setup so that the entire instance gives every HTTP user global administration rights.


That's so you can get started developing quickly. You're supposed to configure your users and permissions before you release to the public, and CouchDB helpfully displays a message in Futon saying, "You're in Admin Party mode!" to remind you of this.


Exactly. Which makes it all the more surprising that this could have happened. As soon as you realize your entire instance is left open by default, it should immediately cause you to check the default security settings on the system databases to see if there is a "party" going on there as well.


There is absolutely nothing to see here as far as CouchDB is concerned - http://stackoverflow.com/questions/4847145/couchdb-adding-us.... Note that this answer from 2011 noting that _users is not intended for storing secure information.

npm effed up is all.


The person who answered the question is involved in hosting NPM.

https://github.com/iriscouch/npm/blob/master/doc/cli/registr...

He doesn't suggest that the password hash is per-user private data. I don't think he caught onto this issue until later.

Besides the misinformation, I disagree about CouchDB's involvement in this mistake. There's no common use case in which using the _users database for human-created passwords wouldn't be a bad idea. For machine-created passwords that are long, it might be OK.

It's just like the Rails issue from a few days back: insecure by design. Only with Rails there was an obvious workaround, which was used by many Rails shops (I was quite surprised to find that it wasn't as many as I thought). With CouchDB you basically have to skip out on one of CouchDB's major features.


If that's the case, then why is CouchDB treating it as a security error, and "fixing" it in 1.2.0? Change of heart?


CouchDB introduced new functionality that allows extra use cases, in particular it can now handle npms use case in a secure manner, just because it didnt handle npms use case before and npm decided to expose that information does not mean it was ever couch's problem.


So just to be clear, this is only a problem for npm package maintainers/admins right? Regular users of npm wouldn't have registry accounts. The headline reads as if the npm client is the risk.


> Reset/change the password of any service that has the same password.

Well this bullshit has to stop. I use the same password on most 'low-risk' sites, and I can't remember them all (can you remember all the blogs you have signed up for?) so I can't 'change the password on all other sites because CouchDB uses a retarded security scheme'.


Password managers.

Not to be snarky or to minimise the impact of yet another critical security bug, but does anyone get the impression that instead of righteous fury the appropriate response to these situations is to assume insecurity and provide information to other parties with the prior understanding that compromise is not just a theoretical possibility? It stands to reason that for every compromise we actually hear about, there is plenty going on behind the scenes that never even emerges from obscurity. That doesn't make it less dangerous.

Encrypt your remote data, make it useless for anyone to compromise anything you have provided to anyone else through password management with autogenerated complex passwords for every last service you use. Use all the tools available to mitigate the impact of a provider security breach.

Most of all, if you can't deal with the potential fallout of a provider's security failing, simply do not use them in the way that requires you to rely absolutely upon their security that you do not have oversight or control over.


>so I can't 'change the password on all other sites because CouchDB uses a retarded security scheme'.

So what? That's the trade off you signed up for when you decided to use the same password for 'low risk' sites.


> I use the same password on most 'low-risk' sites

Here's the actual problem.


And the alternative is to remember more than two or three safe passwords, which I can't. Humans weren't meant to do that.


"Humans weren't meant to do that."

You sound rather defeatist for someone who's on Hacker News. Here's a tip. Create a pattern of sorts, example follows:

    1. Choose a keyboard sequence: say qwerhjkl
    2. Pick 1 < 5 < N.  Use the first N characters of the site/service, followed by N.  npm3qwerhjkl
You now have multiple passwords with an easy mnemonic. The above example may be too obvious a pattern to crack, so come up with a better one.


Hear, hear.

There are so many ways you can do this. It's fast, easy, yet completely unintelligible to a human. My personal favorite is to convolve it with a spatial pattern, like typing the password out in Dvorak while using qwerty. Or use each finger in sequence, with each finger taking a choice of the four keys near it depending on where the site name's letters are (i.e. ycombinator = 1xefmko.qwe).

I find it also helps to have three standard versions - a standard that may contain special characters, one that is guaranteed not to, and second that acts as a fail-safe in the event the password has tight length or character constraints.

It only sounds convoluted - the rules are simple and easy to memorize, and damnably difficult to see a pattern in outside of brute-forcing.


I disagree.

Once you've broken dictionary attacks I think the next goal should be to increase length as easily a possibly.

Personally I prefer a standard prefix/postfix with with a variable competent generated from the site name or url.

This allows you to use different standard substings for different sites depending on their importance. Since the substring can include the dictionary breaking portion you are free to use less complicated generation patterns for the variable part.

The end result should be longer passwords.


This doesn't make sense. If you only used that password on 'low-risk' sites, then you are by definition only at very low risk here, right? So go ahead, don't change anything.


npmjs.org isn't a low-risk site. A weak password is putting users of your npm packages in danger.


If these are random blogs you've signed up for, it probably won't matter too much if someone is able to log in as you. But if you used the same password for your banking you'll probably want to change it.


I don't understand what you are complaining about here. They are warning you that your email address and password might be available to crackers. It then follows that if you are concerned about your security, you change these credentials if you have used them anywhere.

So it's "bullshit" that they've warned you of this?

When you use the same password in multiple sites you are taking the risk that any of those sites could be hacked and your password is put out in the open. CouchDB's security scheme isn't at fault, your personal security scheme is.


You manually type your passwords?


when you need to login to some service on your mobile phone, what do you do? does your password manager sync between your computer and your mobile?


Mine does. 1password has Dropbox sync.


Open app, multitask button, select LastPass, long press, "Copy Password", multitask button, long-press password field, "Paste". Done.


What else? Have a third-party steal all my passwords, at once, rather than just the least critical once?


What else? Have a third-party keylog you with 100% success rate, at once. But I kid I kid, either way, if you are compromised, you're going to lose those passwords no matter what.


Stop using the same password anywhere. There are password management system that do encryption client side, have extensions for every major browser, have mobile apps, support two-factor authentication, will prepopulate both registration and login forms and more.

It's EASIER to use a password manager with very strong, unique passwords than it is to not. Not to mention the eliminated risk of "where did I use this password that just got leaked".

How many more leaks and how many more times do I have to repeat this to get people to take it seriously. Every time people whine that it's too much work (it's not, it seriously isn't) but they don't think about how much of a hassle these leaks can be. NPM, PS3, BitCoin reserves, how many more diverse things need to be hacked for people to realize that its simply a matter of time?


> Stop using the same password anywhere.

You might as well say, "Stop being human." That's never the right solution to network problems that require high reliability.


It's the right solution for anyone who actually cares about security. No amount of indignation (and no amount of concern for security in your own work) will prevent third parties that don't care about security from leaking your data wherever possible.


Network security isn't a person problem, it's a system problem. You can't fix system problems with personal solutions.


But security across multiple sites _has_ to be fixed on the person end, because it can't be fixed on the system end. If you use the same password for 10,000 sites, there's no fix on the 'system' end to make them all secure, because they're all run by different people. It only takes one of them to fuck up.


Third option: there is no "fix," on either end, so telling people to change all their passwords is pointless.


I fixed it for myself by using a password manager. I only have to worry about securing the (encrypted) database, which is comparatively trivial.

I'm still vulnerable to the "supercomputer cracks your encryption" attack but that's orders of magnitude better than having my bank account compromised because some blog leaked my universal password.

Edit: If there were no fix, changing all of your passwords would be the only option besides letting the Internet at large have your accounts. Unless I'm misreading you.


The example was 10,000 sites, so changing all of your passwords being the only option is no option at all.


Good security comes in layers. You are right that you can't control all the layers, but you can make the layers you do control stronger. In today's world (which isn't ideal) that means good password management.


My reccommendation is to use "nonce + domain name" for all of the sites you need passwords for and then hash it.

  $ echo password@$(echo nonce+hackernews.com|md5sum|tr [[:lower:]] [[:upper:]])

  password@FB85C2F638706D4BE4192391387C2879
The above format gives you lower, upper, digit and special character.


I wish I could do something like this all the time, but there are always some sites that force you to put symbols in your password, or to use both lower and upper case, or to be between 6 and 8 characters long, or whatever weird requirement they thought would be a good idea.

And since I can't (and don't want to) remember which sites enforce which restriction, I end up having to resort to writing my passwords in a text file.


https://www.pwdhash.com is a browser extension that does exactly this automatically.

Oh and hash functions won't output symbols or banned chars. They output numbers and you can choose to represent those numbers in whatever mad way that you want, typically as hex, ie. letters and digits.

The length might be a problem but there's nothing to stop you truncating the hash.


Be careful when using PwdHash.

The used hashing mechanism is quite weak. If you don't have a long high-entropy master password, it should be feasible for a site-owner to brute-force your master-password based on the site-specific password.


Yes, but then I have to remember for which sites did I truncate the hash, for which I converted the hash to hexadecimal, etc.


Le mieux est l'ennemi du bien. -- The perfect is the enemy of the good. (Volataire)

What product is going to solve every corner case you can throw at it?

FWIW my example string contained symbols, upper, lower and digits:

password@FB85C2F638706D4BE4192391387C2879


Actually, I don't think you should trust anyone or anything with your passwords except for yourself. Trusting any one system is giving yourself a single point of failure.

EMAIL: - Take the time to learn a couple of strong passwords for your email. You can almost always reset forgotten passwords, don't forget that. - Insure you have two-step login enabled for your email service should it be supported, and make sure you have all the secret questions answers memorised. - By the way, secret questions are stupid. It's easier for me to get you to tell me your mothers maiden name and birthday than it is to make you tell me your password. - Have a phone number and other emails associated with your main email accounts, if possible.

OTHER STUFF: - Never use the same password at one site. - Develop a personal "scheme" that lets you form passwords easily.

For example, combine a couple of short words/sentences you know, some numbers related to the service (e.g. got an 'i' in the URL? add 99), add some #@~!"£$ with similar rules. Develop something that works for you. Now when you approach a service you use, you should already have a solid idea what the password is.

- Write down "reminders" but not actually passwords on paper. Don't label them. Write other things that don't make sense. Put it in your desk draw. - Can't do that? PGP/Truecrypt/bcrypt/whatever a text file.

Forgot your password? Press the forgot password button.


Do they work on all platforms (Linux, Windows, Android, MacOX and IOS)? Do they automatically sync (so I don't end up being locked out of one account)? Can I be sure they won't be shut down and thereby leave me cut of from all my online services?

And what do I do when the password manager is, inevitably, broken into?

It seems to me that a password manager is a great theoretical idea, but they don't really work in practice.


Have you used LastPass? It really works in practice. Syncs instantly to Windows, OSX, Linux, and all major mobile platforms. They were broken into sometime last year, but IIRC they handled the situation superbly, and no passwords were leaked thanks to client-side encryption.

You do need to remember a couple of passwords, though. Your LastPass password and your primary e-mail password (in the unlikely event that LastPass becomes unusable and you need to reset passwords on all of your other accounts).


> Do they work on all platforms (Linux, Windows, Android, MacOX and IOS)?

1password works on all of those except Linux. I believe LastPass works on all.

> Do they automatically sync?

1password syncs to Dropbox.

> Can I be sure they won't be shut down and thereby leave me cut of from all my online services?

Yes, if it syncs to something like Dropbox that has a local copy.

> And what do I do when the password manager is, inevitably, broken into?

The same thing you have to currently do if you're using one password everywhere?


1Password actually has, hidden inside the '1password.agilekeychain' folder, a file called 1Password.html, which can be opened in any modern browser. So you can actually get at your passwords from a Linux machine by opening this .html file and supplying your master password.

I think they call this feature "1Password Anywhere".. I'm surprised they don't talk about it more.


Yes, I love this. I store my 1Password file in Dropbox, so in a pinch, I can log into Dropbox on someone else's computer and grab any password I might need.


>> Can I be sure they won't be shut down and thereby leave me cut of from all my online services?

> Yes, if it syncs to something like Dropbox that has a local copy.

This isn't necessarily true. If Dropbox was legally coerced to do so, they have the technical means to erase any file in your Dropbox from each machine as it connects to the network. I believe they already do a best-effort version of this if someone stops sharing a folder with you. All it would take is a court order to remove a file and all its backups from Dropbox's server, which might happen without even targeting you specifically because Dropbox does deduplication and doesn't encrypt your data.

This may be very unlikely, especially with an encrypted password database unique to you, but it's not impossible. At least we can presume that a general takedown or Dropbox becoming unavailable for whatever reason won't cause this to happen.


My 1password additionally makes periodic local backups of the file.


If you don't use a password manager, how in the world can you comment on how they work in practice? This is a completely uninformed opinion.


Use a local pwd manager like KeePassX or KeePass2, and back up the database to a secure service like Tarsnap or SpiderOak (or both for redundancy).

That way you avoid storing your passwords in a huge hacking target like LastPass, but still get 90% of the utility (no web form autofill, gotta copy and paste, but that's not too intrusive since most sites keep you logged in indefinitely now).


>Do they work on all platforms (Linux, Windows, Android, MacOX and IOS)? Do they automatically sync (so I don't end up being locked out of one account)? Can I be sure they won't be shut down and thereby leave me cut of from all my online services?

Yes, yes, yes (make a text backup, another supported feature, also every device would have a local copy, etc, etc)

>And what do I do when the password manager is, inevitably, broken into?

Why? Because you left it open and unencrypted? How about, just not doing that? Mine is locked every time I close the browser. If you're paranoid only unlock it when you need to enter a site. Not only that, but even if your master password is "stolen" somehow... it's a single password to change and your other passwords are secure. Again, if you're paranoid, you'd at least have a list of the sites that you have to worry about.

>It seems to me that a password manager is a great theoretical idea, but they don't really work in practice.

It seems to me that you really don't understand what is out there or what you're talking about. These things are true of not just LastPass but other solutions as well.


You are right, I don't understand what I out there because I haven't look. Based on your response I have determined that it might be worth looking into, but I don't know which to choose.

But by broken into I mean hacked, as in 'due to $INSECURE_FEATURE $SOMEBODY copied the entire database and now have all your passwords'. If somebody breaks into my home and steals my computer, I can call the police (and activate the tracking beacon).


>But by broken into I mean hacked, as in 'due to $INSECURE_FEATURE $SOMEBODY copied the entire database and now have all your passwords'. If somebody breaks into my home and steals my computer, I can call the police (and activate the tracking beacon).

Like I said, it's all locally encrypted. I trust (at least LastPass's) model well enough that I'd be happy to let you have a copy of all the data LastPass has for me on their server.


CouchDB uses SHA-1 hashes for passwords - you've got to be kidding me. What is the rationale for that over bcrypt?


At the time we choose sha1 because the password hashing for creating new user documents was done by the client, often in the browser. At the time there were no good bcrypt implementations in JavaScript. Here is the related bug tracker issue https://issues.apache.org/jira/browse/COUCHDB-1060


Speed. Bcrypt is much slower.


That's part of bcrypt's reason for existing. In order to protect against brute-forcing stolen hashes, bcrypt has to be slow enough to make brute force impractical. This isn't a bug; it's a necessary feature. If the server they're running npm on is so old or so overloaded that the slowdown from using bcrypt would even be particularly noticeable, then they have other problems.


Oh it can surely run bcrypt for a few users. The question is if it can run it for a couple thousands a minute.

I am not so sure of that.


The sites that have easily scaled bcrypt include many so large that this argument has basically been mooted, but if you want to nerd around with it: you would hypothetically just turn the cost factor down to accommodate load.


It doesn't need to run it for a couple thousand a minute, there aren't that many people registering with NPM at any given time.


Sure, but how many people are using it? You would need to verify the password on each request (since you can't use browser cookies).


The operations npm needs to log in for are a fairly small percentage of the total. If you need to upload a new version of a package, then that takes a password. If you just need to search for a package, or download its latest version, those don't need authentication. The overhead from using proper slow password hashing would be minimal.

And evidently the CouchDB guys agree with me, because they switched to using PBKDF2 for password storage -- essentially, iterate SHA several thousand times to make it slower.


Wouldn't npm client be sending the hashed version of the password rather than the password itself? then the server only has to compare the two hashes.


Is it so unreasonable to force everyone to change their password?


Thundering herd problem with emails. Are there any email startups that can help out? isaacs email is on OP link.


Software which is supposed to be installed by running under sudo a shell script wgetted from a site somewhere without ever reviewing it ends up leaking all passwords.

As surprising as getting lice after you let a hobo sleep in your bed.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: