Comment by lrvick | Hacker News Reader

Comment by lrvick | Hacker News Reader

Parent Full thread

I checked the password-reset flows for most major NPM contributors that use regular webmail accounts like Gmail too.

< 10% had useful 2FA enabled. Most were just password reset questions or had a backup email to some old expired and re-registerable forgotten earthlink accounts etc.

I do this stuff all the time. I looked up the password reset questions controlling the zoom.us domain 2 years ago and collected an insulting $200 bug bounty for it. Zoom, like NPM, didn't do signed binaries, so this would have been brutal combined with other issues I found.

The solution is what all sane OS package managers do: code signing.

NPM has rejected this at least as far back as 2013 when they refused a PR by someone that implemented it for them: https://github.com/npm/npm/pull/4016

I don't know what else to do but keep publicly trolling them at this point until code signing is implemented. Unsigned code is a free pass for remote code execution when an account gets taken over.

Meanwhile Debian maintains hundreds of signed nodejs packages proving it is very doable by a low budget team. NPM seems to just want to reduce deveopler friction at all costs :/

The question in that thread, and this later thread,[1] is how to know which keys are valid to sign a package.

For example: I go to release a new version and I've lost my private key, so I roll a new one -- this will happen often across npm's 1.3 million packages. Do I then ... log in with my email and update the private key on my account and go about my business? What process does npm use to make sure my new key is valid? Can a person with control over my email address fake that process? How are key rotations communicated to people updating packages -- as an almost-always-false-positive red flag, or not at all, or some useful amount in between? If you don't get this part of the design right -- and no one suggests how to in those threads -- then you're just doing hashes with worse UX. And the more you look at it, the more you might start to think (as the npm devs seem to) that npm account security is the linchpin of the whole thing rather than signing.

It's not just npm; that thread includes a PyPI core dev chipping in with the same view: "Lots of language repositories have implemented (a) [signing] and punted on (b) and (c) [some way to know which keys to trust] and essentially gained nothing. It's my belief that if npm does (a) without a solution for (b) and (c) they'll have gained nothing as well." It also has a link from a Homebrew issue thread deciding not to do signatures for the same reason -- they'd convey a false expectation without a solution for key verification.[2]

[1] https://github.com/node-forward/discussions/issues/29 [2] https://github.com/Homebrew/brew/pull/4120#issuecomment-4068...

You could make it optional and never permit key updates. Then downstream users could decide to only depend on signed code. The downside of this is some people will lose their keys and never be able to update a project ever again. The upside of this is that businesses that prioritize this can be more confident that an account takeover isn't shipping them evil code.

> What process does npm use to make sure my new key is valid? Can a person with control over my email address fake that process?

It seems there should be some multi-factor process.

Developers need to register a password, an email address, and a YubiKey/TOTP token. If they lose access to the email address, they can log in to their account with the password and token. If they lose the token, they can be issued a new one with the email and password (or recovery codes).

As long as the account stays secure (i.e. an attacker doesn't manage to keylog the developer's NPM password and email password) then the NPM account can be trusted to add new package signing keys. The npm client then needs to trust metadata from NPM which vouches for these new keys.

For all that people love to hate it, GPG's web of trust could cover this. Lost your key? That's fine; go convince a dozen peers that that's what happened and you're really you and they'll cross-sign your new key.

Debian already maintains hundreds of signed NodeJS packages using classic PGP web of trust, with a team of volunteers that lack NPM microsoft money. I don't understand how NPM has any excuses at this point

The web of trust PGP signing approach works reasonably well to protect most linux servers in the world since the 90s. You can complain about it and say there should be a better UX toolchain for it, and I would agree with you. Thankfully the sequioa-pgp team has made huge progress here and it is a shame they are not getting due support for their heroic and near thankless efforts to make this better.

Still, even with todays GnuPG tools, abandoning pgp for supply chain integrity and replacing it with nothing is crazy. Imagine if we abandonded TLS because early implementations sucked. Use the best tools we have then fight to make them better. That's just good engineering.

The software eng commuity at large basically said "Look we just stopped signing code and nothing bad happened... oh wait bad things are happening. Too late to change now!"

This was a reasonably well solved problem, but entities like NPM will need to have the humility to admit that rejecting best effort cryptographic authorship attestation was a mistake.

> < 10% had useful 2FA enabled.

I expect this to change. NPM will roll out mandatory MFA for the most-downloaded packages[0] (RubyGems as well[1]). I expect this will rise to a 100% requirement at some point because Github's decision to require MFA by the end of 2023 will massively raise the waterline of folks who have the capability to MFA and experience with MFA.

[0] https://github.blog/2021-11-15-githubs-commitment-to-npm-eco...

[1] https://github.com/rubygems/rfcs/issues/35

Doesn't really even need to reduce average developer friction - they've proven a few times that they're happy to add extra security requirements just for publishers of high-visibility packages.

"Once you cross 100,000 weekly downloads, all new publishes must be signed" would keep the easy on-ramp for small packages but dramatically reduce the risk of major attacks against all the big targets (like the example here).

Not as good as signing everything, but a good start that can be iterated on later.

Is code signing really a solution here? It seems more like a bandaid to me, because someone without MFA on their account probably also doesn't have the best security around their code signing. In any case, isn't it often handled by CI/CD? If you get access to the developer's account, you can release malicious code, dutifully signed?

Technically what's needed is attestation: I don't care if the author signs it, I care that trustable third parties have reviewed it.

Most people would have no problem marking a couple of big firms and orgs as trusted reviewers and only showing packages to be used if signed by them.

What folks call signing is, if you step back, basically another kind of attestation. It's an attestation of authorship.

To be honest, rather than magical blessed keys held by a few orgs, I'd feel more comfortable with a slightly larger number of individual reviewers (and prosaic keys), each with some kind of visible distance metric related to the codebase they're signing artifacts for.

For example: "ah yes, a core contributor, a frequent code reviewer, and two downstream consumers of this library have signed off on the changes in this release. even if one of them is having a distracted day/week, that's good enough for our team to be comfortable upgrading it today since it's a minor version upgrade"

Sure: I don't think any of this should go the way of TPM and EFI (magic primary keys held by those big enough to have legal departments for the committees) - but it's a short hand to acknowledge that almost everyone would mark "Google and Microsoft internal use approved" package keys as absolutely trusted and mostly not worry about it.

That seems like it'd be a way for those companies to attempt to capture the technical infrastructure used by packages, and hold their adoption potential hostage (soft pressure for packages to change their practices to become approvable, and latterly a hope that the wider community will tend to believe in and trust those approvals).

You could be correct, maybe this would work in practice, trading on the reputations of those companies. It doesn't feel particularly open or community-oriented, though. Why not present a trust graph built from a broad set of worldwide users instead?

(one of the benefits to a trust graph would be the volume of signers; perhaps you wouldn't want to weight each signing equally -- again referring back to something like the distance metric mentioned previously -- but for even mid-popularity packages, the detailed review possible by careful users of a package could, I expect, be more reliable than automated-and-manual review by one or two large companies)

> I don't know what else to do but keep publicly trolling them at this point until code signing is implemented.

I don't think your trolling is doing you any favours anymore (sigh, that guy again). Kicking a dead horse etc. Maybe just let it go?

As long as negligence keeps getting people hurt, I will keep trying to call it out and prevent more negligence. If that means being That Guy then so be it.

In parallel I am writing specs and proposals for widely applicable tooling and improvements.

Reply on news.ycombinator.com