
Half of all JavaScript npm packages could have been hacked via weak credentials - whitewalls
https://www.bleepingcomputer.com/news/security/52-percent-of-all-javascript-npm-packages-could-have-been-hacked-via-weak-credentials/
======
robocat
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 password by adding a ! to it at the end.

* While Skovoroda discovered credentials that granted him direct publish access to only 13% of npm packages, through dependencies, an attacker would have been able to spread his malicious code to about 52% of the entire npm ecosystem.

There is no bandaid to fix this structural issue.

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

~~~
stickfigure
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 for
dependencies. A fake release might affect folks downstream that explicitly
choose the upgrade, but it won't be automatic.

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.

~~~
always_good
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.

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

------
BenjaminCoe
worth mentioning, since this article npm has released two-factor
authentication \o/

[http://blog.npmjs.org/post/166039777883/protect-your-npm-
acc...](http://blog.npmjs.org/post/166039777883/protect-your-npm-account-with-
two-factor)

make sure you turn it on.

~~~
paxy
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 minimum level of security.

~~~
cjcampbell
I like the direction you’re heading with this, as it touches on supply-chain
issues that have most folks just throwing their hands up. What would be most
interesting is a standard framework for expressing a security policy combined
with some hooks in the build tooling.

I also wonder whether it would be appropriate for the repositories themselves
to hold maintainers to a minimum standard as well as their own claims. E.g.,
package maintainers must set a >12 character password and employ 2fa.

In reality, this isn’t just an NPM issue. I suspect that similar issues plague
just about every package management framework, App Store, or CDN out there.
Having a couple of standardized approaches would enable developers who care to
automate checks and start to generate new incentives for the folks that are
publishing their work to follow some basic standards.

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

~~~
tomelders
Heheh, welcome to JavaScript kid! Hold on tight!

~~~
inopinatus
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).

~~~
z3t4
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.

------
z3t4
I think key based authorization should work great in NPM. Why are they not
using keys ? Passwords should only be used to unlock keys.

------
peterwwillis
So, why is it they're not using certificates?

~~~
jclulow
I can imagine this would lead to a rash of certificates committed to
repositories on GitHub.

~~~
peterwwillis
My bad - I said certificates when I meant public key crypto. They would only
check in a public key.

------
k__
Is this even a problem with a lockfile?

I mean even if an account is high jacked the packages must conform to a hash.

------
flavio81
Obligatory HN reminder that the NPM system is crap and you shouldn't be using
it.

~~~
dang
Please don't post like this; it breaks the site guidelines and discredits both
your point and you.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

This applies regardless of whether your underlying view is correct.

~~~
flavio81
I'm sorry.

I should have said that NPM is fundamentally and essentially flawed, and that
HN readers should not use it, favoring alternatives like Yarn instead.

~~~
dbrgn
Isn't yarn also accessing npm repos? Also, in 99.9% of the cases yarn is
installed through npm.

