9 ms·

npm (Node's package manager) leaks all user password hashes and salts

151 points by jashkenas 15y ago

jashkenas 15y ago
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.
- throwawaysnipe 15y ago
  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?
  - jashkenas 15y ago
    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.
    - throwawaysnipe 15y ago
      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.
- daleharvey 15y ago
  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
  - moe 15y ago
    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...
    - swannodette 15y ago
      http://guide.couchdb.org/draft/security.html http://guide.couchdb.org/draft/security.html
    - daleharvey 15y ago
      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.
      - rhizome 15y ago
        Process security is very common even when the process listens only on a socket.
      - grannyg00se 15y ago
        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.
        daleharvey 15y ago
        it listens on 127.0.0.1, not not on an external interface, it is not exposed by default
        grannyg00se 15y ago
        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.
- grannyg00se 15y ago
  Also worth noting: By default, CouchDB is setup so that the entire instance gives every HTTP user global administration rights.
  - LeafStorm 15y ago
    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.
    - grannyg00se 15y ago
      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.
tomjen3 15y ago
> 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'.
- cbs 15y ago
  >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.
- smarmius 15y ago
  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.
- Legion 15y ago
  > I use the same password on most 'low-risk' sites Here's the actual problem.
  - tomjen3 15y ago
    And the alternative is to remember more than two or three safe passwords, which I can't. Humans weren't meant to do that.
    - throwawaysnipe 15y ago
      "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.
doki_pen 15y ago
Thundering herd problem with emails. Are there any email startups that can help out? isaacs email is on OP link.
brown9-2 15y ago
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.
shocks 15y ago
Is it so unreasonable to force everyone to change their password?
mrduncan 15y ago
CouchDB uses SHA-1 hashes for passwords - you've got to be kidding me. What is the rationale for that over bcrypt?
- tomjen3 15y ago
  Speed. Bcrypt is much slower.
  - pjscott 15y ago
    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.
    - tomjen3 15y ago
      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.
      - grandpoobah 15y ago
        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.
        tomjen3 15y ago
        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).
        pjscott 15y ago
        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.
swannodette 15y ago
There is absolutely nothing to see here as far as CouchDB is concerned - http://stackoverflow.com/questions/4847145/couchdb-adding-user-profile-attributes-in-user-documents 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.
- jashkenas 15y ago
  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?
  - daleharvey 15y ago
    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.
- benatkin 15y ago
  The person who answered the question is involved in hosting NPM. https://github.com/iriscouch/npm/blob/master/doc/cli/registry.md 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.
cheatercheater 15y ago
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.

151 points by jashkenas 15y ago

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.

throwawaysnipe 15y ago
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?
- jashkenas 15y ago
  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.
  - throwawaysnipe 15y ago
    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.
daleharvey 15y ago
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
- moe 15y ago
  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...
  - swannodette 15y ago
    http://guide.couchdb.org/draft/security.html http://guide.couchdb.org/draft/security.html
  - daleharvey 15y ago
    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.
    - rhizome 15y ago
      Process security is very common even when the process listens only on a socket.
    - grannyg00se 15y ago
      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.
      - daleharvey 15y ago
        it listens on 127.0.0.1, not not on an external interface, it is not exposed by default
        grannyg00se 15y ago
        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.
grannyg00se 15y ago
Also worth noting: By default, CouchDB is setup so that the entire instance gives every HTTP user global administration rights.
- LeafStorm 15y ago
  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.
  - grannyg00se 15y ago
    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.

tomjen3 15y ago

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

cbs 15y ago
>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.
smarmius 15y ago
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.
Legion 15y ago
> I use the same password on most 'low-risk' sites Here's the actual problem.
- tomjen3 15y ago
  And the alternative is to remember more than two or three safe passwords, which I can't. Humans weren't meant to do that.
  - throwawaysnipe 15y ago
    "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.

doki_pen 15y ago

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

brown9-2 15y ago

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.

shocks 15y ago

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

mrduncan 15y ago

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

tomjen3 15y ago
Speed. Bcrypt is much slower.
- pjscott 15y ago
  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.
  - tomjen3 15y ago
    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.
    - grandpoobah 15y ago
      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.
      - tomjen3 15y ago
        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).
        pjscott 15y ago
        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.

swannodette 15y ago

There is absolutely nothing to see here as far as CouchDB is concerned - http://stackoverflow.com/questions/4847145/couchdb-adding-user-profile-attributes-in-user-documents 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.

jashkenas 15y ago
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?
- daleharvey 15y ago
  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.
benatkin 15y ago
The person who answered the question is involved in hosting NPM. https://github.com/iriscouch/npm/blob/master/doc/cli/registry.md 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.

cheatercheater 15y ago

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.