Hacker News Reader

Comment by BenjaminCoe | Hacker News Reader

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

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.

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.

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

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.

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.

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 <0.5% of all packages, and <1% of top 1000. You don't get 2FA without the beta client right now anyway.

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 dependency trees and malicious packages that's worth a read:

https://duo.com/blog/hunting-malicious-npm-packages

> 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/<pkg> eventually. That will increase awareness and highlight those that don't have 2FA.

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.

Reply on news.ycombinator.com