3 ms·

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 ju

by lrvick 5y ago

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 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 :/

pimterry 5y ago
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.
sofixa 5y ago
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?
- XorNot 5y ago
  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.
  - jacques_chester 5y ago
    What folks call signing is, if you step back, basically another kind of attestation. It's an attestation of authorship.
  - jka 5y ago
    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"
    - XorNot 4y ago
      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.
      - jka 4y ago
        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)
dncornholio 5y ago
> 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?
- lrvick 4y ago
  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.
JackC 5y ago
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 https://github.com/node-forward/discussions/issues/29 [2] https://github.com/Homebrew/brew/pull/4120#issuecomment-406879969 https://github.com/Homebrew/brew/pull/4120#issuecomment-4068...
- UncleMeat 5y ago
  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.
- dane-pgp 5y ago
  > 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.
jacques_chester 5y ago
> < 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-ecosystem-security/ https://github.blog/2021-11-15-githubs-commitment-to-npm-eco... [1] https://github.com/rubygems/rfcs/issues/35 https://github.com/rubygems/rfcs/issues/35

by lrvick 5y ago

pimterry 5y ago

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.

sofixa 5y ago

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?

XorNot 5y ago
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.
- jacques_chester 5y ago
  What folks call signing is, if you step back, basically another kind of attestation. It's an attestation of authorship.
- jka 5y ago
  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"
  - XorNot 4y ago
    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.
    - jka 4y ago
      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)

dncornholio 5y ago

> 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?

lrvick 4y ago
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.

JackC 5y ago

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 https://github.com/node-forward/discussions/issues/29 [2] https://github.com/Homebrew/brew/pull/4120#issuecomment-406879969 https://github.com/Homebrew/brew/pull/4120#issuecomment-4068...

UncleMeat 5y ago
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.
dane-pgp 5y ago
> 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.

jacques_chester 5y ago

> < 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-ecosystem-security/ https://github.blog/2021-11-15-githubs-commitment-to-npm-eco... [1] https://github.com/rubygems/rfcs/issues/35 https://github.com/rubygems/rfcs/issues/35