Live data from Hacker News

Half of all JavaScript npm packages could have been hacked via weak credentials

bleepingcomputer.com

21–30 of 38 posts

Re: Half of all JavaScript npm packages could have been hacked via weak credentials

#21
post #10

Earlier quoted context omitted.

I don't see how any of these reasons are why npm is "fundamentally insecure" any more than any other system involving humans.

The npm community has a longstanding habit of depending on dynamic version numbers, eg "^1.2.3". Until the recent advent of package-lock.json, normal builds would pull in "whatever was latest"; any compromised upstream dependency would automatically propagate downstream as fast as their CI systems run. Also, builds are pretty much irreproducible. The maven world, by contrast, is habituated to fixed version numbers fo…

package-lock.json doesn't do anything for security unless you're going to walk the upgrades of each transitive dependency before you run `npm upgrade` (since each dependency can run arbitrary code while installing). So I wouldn't say it solves any of the security issues, just gives you a commitable snapshot of your deps.

One of the many things the npmjs.com website needs to do is provide a code viewer for each version of a package. It's a bit annoying that you have to unpack a tarball just to see the code you're going to be running if you install it. Right now everyone just takes for granted that if a NPM package links to a Github repo, that that's the code you're going to be executing.

Nothing is going to solve the explosion of transitive deps though without some sort of cultural change. I don't see that ever happening. I do like the ecosystem of tiny libraries but it's too large of a trade-off for security sensitive applications imo.

Re: Half of all JavaScript npm packages could have been hacked via weak credentials

#22
It's amazing that Node.js comes with a package manager that is not fully open source and is entirely controlled by a private corporation

NPM has some serious issues and unlike node itself we can't fix them because we don't have access to all of the source code.

Npm decided to auto close most of issues raised by its users in Github without addressing them. Many of those bugs still exist, even in the latest version.

It's a shame that the community of all those awesome package maintainers is being monetized by a corporation that is mostly dysfunctional and incompetent.

Re: Half of all JavaScript npm packages could have been hacked via weak credentials

#23

We're building everything on quicksand. I'm constantly amazed anything ever works.

Heheh, welcome to JavaScript kid! Hold on tight!

For those of us building anything that processes information with any level of sensitivity, it's not so funny. It's almost impossible to verify the integrity of JS dependencies.

I've had to adopt a policy of ignoring anything but the most carefully curated and dependency-minimised JS packages, and to avoid the language in general except when it can't be generally circumvented (i.e. in the browser).

Re: Half of all JavaScript npm packages could have been hacked via weak credentials

#24
post #10
post #8

The npm ecosystem is fundamentally insecure. Some highlights: * I obtained accounts of 4 users from the top-20 list. * One of those 4 users set their password back to the leaked one shortly after it was reset. * 13 users [that I found the password for] had more than 50 million downloads/month. * One of the users directly controlling more than 20 million downloads/month chose to improve their previously revoked leaked…

I don't see how any of these reasons are why npm is "fundamentally insecure" any more than any other system involving humans.

Perhaps look at an OS packaging system. Debian has a particularly robust one, and it simply couldn't be brute-forced like this (as it's key-based).

Even just simply forcing 2FA would be a significant improvement.

Re: Half of all JavaScript npm packages could have been hacked via weak credentials

#25
post #10

Earlier quoted context omitted.

I don't see how any of these reasons are why npm is "fundamentally insecure" any more than any other system involving humans.

The npm community has a longstanding habit of depending on dynamic version numbers, eg "^1.2.3". Until the recent advent of package-lock.json, normal builds would pull in "whatever was latest"; any compromised upstream dependency would automatically propagate downstream as fast as their CI systems run. Also, builds are pretty much irreproducible. The maven world, by contrast, is habituated to fixed version numbers fo…

> package-lock.json helps solve the technical problem, but the JS community still has a cultural problem because JS packages are typically fine-grained, released frequently, and upgraded without much thought.

Just the other day I caught myself feeling frustrated that I had to manually add a dependency + version number in my mix.exs (Elixir package manager), just because I got so used to doing 'yarn add '.

And that's despite the fact that I for quite a while now I have also been feeling a bit weird about just adding packages to my project for the exact reason discussed here (as well as the 'leftpad' fiasco).

It's both fascinating and a bit scary how easy I just do things 'the way everyone does' despite knowing better, and I hope we'll find some solution that could be applied community- or ecosystem-wide.

Re: Half of all JavaScript npm packages could have been hacked via weak credentials

#26

worth mentioning, since this article npm has released two-factor authentication \o/ http://blog.npmjs.org/post/166039777883/protect-your-npm-acc... make sure you turn it on.

I tried to use it over the weekend, but the CLI didn't recognize `npm profile`, even after I made sure I was on the latest version of npm.

Re: Half of all JavaScript npm packages could have been hacked via weak credentials

#28

Earlier quoted context omitted.

Heheh, welcome to JavaScript kid! Hold on tight!

For those of us building anything that processes information with any level of sensitivity, it's not so funny. It's almost impossible to verify the integrity of JS dependencies. I've had to adopt a policy of ignoring anything but the most carefully curated and dependency-minimised JS packages, and to avoid the language in general except when it can't be generally circumvented (i.e. in the browser).

And people think I'm crazy for keeping track of dependencies via SCM. Many packages now a day is compile to JS, eg they have 100,000 build dependencies, but all you need is actually just two or thee files, the rest can be deleted.

Re: Half of all JavaScript npm packages could have been hacked via weak credentials

#29

Earlier quoted context omitted.

I'm curious what the percentage of npm publishers that have this toggled on is, and I wish that was available data. First, in terms of all packages, and then of top 1000 packages. I'll wildly guess It's of no surprise to anyone that follows Node.js security at this stage that the third party dependency chain is really its biggest weak link. Jordan Wright did some good research a couple of months ago on Node dependenc…

> I'm curious what the percentage of npm publishers that have this toggled on is, and I wish that was available data. I know we're tracking this data and I bet a follow up post will be written at some point once some numbers are available. As you say, I expect 2fa will see wide adoption as soon as a stable version lands in the upstream Node.

I hope that accounts will have some badges on npmjs.org/ eventually. That will increase awareness and highlight those that don't have 2FA.

Re: Half of all JavaScript npm packages could have been hacked via weak credentials

#30
post #6

worth mentioning, since this article npm has released two-factor authentication \o/ http://blog.npmjs.org/post/166039777883/protect-your-npm-acc... make sure you turn it on.

The problem with measures such as 2FA is that they are voluntarily implemented only by users who are most concerned about security, whereas users setting their password to "password" are on the opposite end of the spectrum. What we really need is (1) 2FA and other enhanced security measures and (2) the ability to exclude all packages from a project, whether imported directly or indirectly, that do not abide with a mi…

With a good password policy and mandatory 2FA and (GPG) signing, npm would actually be pretty damn trustworthy.

That's too much "friction", though, so I expect it to remain in this sorry state it has been in.

Post reply on HN