Live data from Hacker News

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

bleepingcomputer.com

11–20 of 38 posts

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

#11
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.

maybe there should be some type of 2 factor authorization to make sure you can't get in by guessing someone's insecure password, or grabbing it from a leak (due to password reuse).

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

#12
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…

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.

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

#14
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…

This is exactly what is needed. Publish on each user's profile whether their account is secure, and provide an option in the client to disallow upgrading package versions owned by users that don't comply.

You could even try to crack the password of any user with enough (by some threshold) downloads using known leaked passwords as seeds, and mark them as insecure and reset their password if successful.

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

#15
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…

That seems less of an indictment of npm and more an indictment of JS developers not caring about or understanding basic information security principles.

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

#16

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

Heheh, welcome to JavaScript kid! Hold on tight!

Just wait till everything runs in a web browser. But by then you'll be able to convert your Rust program to web assembly to draw UIs on the canvas for VR apps.

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

#17
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…

It seems like a no-brainer that any accounts on the main npm repos would _have_ to have 2FA enabled.

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

#18
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…

You're talking about actions that security-minded parties could take already, if they cared to do so. Run your own registry, and audit everything that goes in, before it goes in. That would be a lot of work, but it would actually affect security to some degree. This idea that packages will be safe if only we inconvenience all package authors enough is just silly.

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

#19
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.

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.

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

#20
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.

What makes this a problem is that the NPM ecosystem has so many transitive dependencies. Which is why a left-pad fiasco can even happen in the first place.
Post reply on HN