9 ms·

Top-500 NPM package maintainers now require 2FA

124 points by cute_boi 4y ago

qualudeheart 4y ago
Finally. NPM has been a security nightmare for too long.
bob1029 4y ago
I feel like there are still too many hands in this particular cookie jar. MFA or no. On average, how many other organizations & human developers are somehow involved in the dependency graph of a modern node.js project? I fail to see how MFA resolves the fundamental trust equation. Bad code is bad code, doesn't matter what the authentication system says about the actor's identity. I can create 2FA-enabled GH accounts all day named after JK Rowling characters without anyone at GH sending me a security nastygram or banning me for identity violations. Until GitHub requires government-issued photo ID in addition to MFA, I don't think you are going to properly discourage bad or criminal actors. To be clear: I strongly disagree with any notion that GitHub should require photo ID to open an account. But, perhaps a "verified user" option (extending to "verified org" if all users are compliant) might provide another path.
- TAForObvReasons 4y ago
  OpenSSF, which includes Google and Microsoft, has discussed real name verification requirements. That's definitely where the big money is pushing
- yjftsjthsd-h 4y ago
  > Until GitHub requires government-issued photo ID in addition to MFA, I don't think you are going to properly discourage bad or criminal actors. As a nice bonus, this is a great way to stop people from contributing to projects for free out of the goodness of their hearts. /s
  - Aeolun 4y ago
    How so? I’m already contributing with an account that is astoundingly easy to resolve to my real name. Adding government issued ID to that equation would change nothing for me. I guess it might be problematic if you want to contribute to politically controversial stuff.
    - teddyh 4y ago
      This is the most literal version of “I have nothing to hide, so therefore neither does anyone else” I have seen in recent times.
      - Aeolun 4y ago
        Nowhere do I say that nobody has anything to hide. Hell, I have stuff to hide, but none of that is connected to my public Github account. I was simply challenging the assertation that contributions would dry up when required to identify yourself, and I don’t think that’s true. I can’t be the only one that has only a mildly pseudonymous account.
    - zorpner 4y ago
      Is the assertion here that people who have a troublesome family history, or a stalker, or debt, or who wish to change their lives, or are from a place where their social or racial group might be persecuted, or who simply wish to write code separately from their day-to-day, should not be allowed to do so?
    - yjftsjthsd-h 4y ago
      It's nice that you Have Nothing to Hide, but not everyone wants to - or can - live like that. It's not just politically sensitive stuff (though that's a good reason); some of us like having privacy, and there's no reason that we should have to give up our pseudonymity or anonymity in order to share our code with the world.
      - tomnipotent 4y ago
        An individuals anonymity does not take precedence over a professional supply chain that requires transparency, especially in the context of Top-N packages. The Linux kernel is one such example that does not accept anonymous contributions.
- joekrill 4y ago
  > I feel like there are still too many hands in this particular cookie jar. MFA or no. On average, how many other organizations & human developers are somehow involved in the dependency graph of a modern node.js project? What does that really matter, though? You could ask the same of _any_ modern application, NodeJS or otherwise: "On average, how many other organizations & human developers are somehow involved in the dependency graph of a modern application?". Look at your web browser alone. You have an open source rendering engine. The JavaScript engine. The underlying libraries used to handle things like SSL, TCP/IP, DNS lookups. It runs on an OS that likely has layers and layers of open source code. Which runs on hardware from various manufacturers with firmware written by many people spread across many organizations.
  - Santosh83 4y ago
    The difference is people have become conditioned to trust corporations and organisations, so the software/hardware you mentioned have people or addresses who must answer if they get compromised. Whether they answer is a different thing, and whether this is a good model for everyone is another question. NPM packages on the other hand are dependent on random individuals for integrity and society doesn't trust individuals as much as registered entities, especially profit making ones.
- rektide 4y ago
  First, yes: there absolutely should be better tools for authors to sign & authenticate their own tools, with heightened cryptographic authentication means. Projects like sigstore get this (and wish to respect privacy![1]). But what's spoken of here is a deep imposition, and doesn't empower authors, but demands of them. > I fail to see how MFA resolves the fundamental trust equation Nothing ever will. Your desire for a cathedral is incompatible fundamentally & at every level with the bazaar. Trying to drive open-source society towards an industrialized security state for the convenience of your probably non-contributing, not-paying industrialized software production needs is vastly unfair. If you have needs, you need to take your own responsibility. If you have risks, you need to pay to hedge them. Go hire NodeSource to help you get the Certified Modules you can trust. Go sign contracts with authors to get the support you need. Heck, just checkin your package-lock.json and go see what you are downloading: npm is immutable! You could literally do anything to help safeguard yourself, but you ask for absolute protection, something that even the biggest best corporations can never truly promise. Trying to prevent even one reasonably placed malicious employee from causing disruption is a near impossible task. But you ask for a fundamental safety. This is laughable. None of us can expect nor deserve that. > Until GitHub requires government-issued photo ID in addition to MFA What a vile & fascist imposition this would be! Woe be unto us if industrialzied software so hotly presses for it's own security that it embraces such ludicrous & perverse a cowardice as this. Relying on github as your source of trust, and pressuring them to pressure the world into turning over core information, is just as antithetical as I can image to the open source behavior & society that has advanced us so far. What a terrible thing to wish for! Egads, gross. [1] https://blog.sigstore.dev/privacy-in-sigstore-57cac15af0d0 https://blog.sigstore.dev/privacy-in-sigstore-57cac15af0d0 https://news.ycombinator.com/item?id=31533997 https://news.ycombinator.com/item?id=31533997
  - strawhatguy 4y ago
    Thank you for writing this; far too much entitlement, far too much blame shifting in the parent comment. Ultimately problems with your code, including deps it pulls in, are your problem, no one else's. Code appropriately.
    - 4y ago
- doliveira 4y ago
  Do we need to go this far? Why not just require a DNS which is what all of web security is centered around anyway? Most "serious" packages in Maven Central do have a dedicated DNS, for instance, even though there's the fallback of using io.github.username as the namespace. I feel like providing a namespace and starting to incentivize for it to correspond to a real DNS would be a good start.
- grenran 4y ago
- my69thaccount 4y ago
  > Until GitHub requires government-issued photo ID in addition to MFA, I don't think you are going to properly discourage bad or criminal actors. To be clear: I strongly disagree with any notion that GitHub should require photo ID to open an account. But, perhaps a "verified user" option (extending to "verified org" if all users are compliant) might provide another path. this is absolutely dystopian. Please don't give microsoft any more ideas.
- Gordonjcp 4y ago
  Any government in particular? What about software developers that don't drive?
- arinlen 4y ago
  > Until GitHub requires government-issued photo ID in addition to MFA, I don't think you are going to properly discourage bad or criminal actors. This suggestion sounds like a way to create new and far bigger problems without doing anything to solve the original problem. Let's keep the problem in perspective, shall we? You want to freely access code contributed by someone over the internet, and you want to trust it's provenance. This does not change at all if you throw government-issued IDs into the mix, nor does this affect any of the attack vectors exploited by bad actors.
mrtweetyhack 4y ago
codedokode 4y ago
Sadly, 2FA won't help against malicious developer or a developer selling package to a malicious owner. Maybe ther should be a paid service that would manually review packages and provide a curated repository? I can't see other solutions. Either you review the code or you pay someone to do it or you isolate every library into a sandbox.
- doliveira 4y ago
  At the very least Maven-style DNS-based namespaces would be quite welcome... Then these authentication schemes or even "reputation" becomes DNS based which is much easier to do. Instead of having this random cutoff of popularity. I don't really get why all these package managers don't copy this from the Java world.
protomyth 4y ago
So, how exactly does this work for the random developer that somehow ends up in the top 500 but doesn't have 2FA turned on?
- sheetjs 4y ago
  Hi, random developer that somehow ended up in the top 500 but didn't have 2FA turned on (https://www.npmjs.com/package/xlsx https://www.npmjs.com/package/xlsx)! npm inc invalidated all of our authentication tokens in mid April and we have been unable to sign in via the web interface since then. Assumably the same fate befalls other random devs.
  - smoldesu 4y ago
    Sounds like a pretty bad policy if that inhibits your ability to respond to critical security flaws in your package.
    - _ofdw 4y ago
      The npm ecosystem has been shown over and over again to be a dysfunctional tire fire. I feel like at this point continuing to publish on npm is kind of a "that's what you get" situation.
  - protomyth 4y ago
    Did they tell your users that they locked out the developers? Uhm.... I kinda of expected some mediation or a step-by-step, but that just a dumpster fire solution.
  - tedmiston 4y ago
    > npm inc invalidated all of our authentication tokens in mid April and we have been unable to sign in via the web interface since then This sucks, but invalidating the pre-2FA tokens is unavoidable if their goal is to tighten security of top packages. I don't know how this went down behind the scenes, but hopefully they announced giving you some long enough window like 60–90 days before the old tokens were invalidated. However, what does invalidating your old tokens have to do with signing into the web app that uses your username and password?
capableweb 4y ago
> Don't worry, if you want to automate publishing in CI/CD you can use an Automation Token to allow for publishing via token only without 2FA. From npm. Does this no longer apply? People can't publish from CI anymore as 2FA is now required?
- seniorsassycat 4y ago
  Tokens should still be allowed. Considering TOTP is just a shared secret there's no reason to requre it on top of tokens.
ashishbijlani 4y ago
Have they already enforced 2FA? The tool that I built to detect "risky" NPM/PyPI packages [1] still shows expired email domain for browserify (a top NPM package) 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj
- oefrha 4y ago
  Well, it’s probably only enforced if you submit a new version; can’t really disable a top package just because the author hasn’t logged in in a while. browerify was last updated two years ago and probably won’t see a new release ever, so the requirement doesn’t actually matter.
  - Mathnerd314 4y ago
    Browserify had a PR merged on master in March for switching from non-ECMA String.substr to String.slice: https://github.com/browserify/browserify/pull/2036 https://github.com/browserify/browserify/pull/2036 Apparently it's too trivial for a release but the maintainers still seem to be around. Substack.net listed in package.json seems to be working: https://substack.net/cv.html https://substack.net/cv.html
throwaway0x7E6 4y ago
I can only recall a couple npm dramas where the developer had their account compromised. 9 times out of 10 the culprit is some leftpad tier dependency this ain't gonna do shit about Kony 2022 activism either, which is definitely going to be the next big thing
nsonha 4y ago
Why not just require it for all public packages?
- abraham 4y ago
  > The final cohort will be high-impact maintainers of packages with more than one million weekly downloads or 500 dependents later this year. https://github.blog/2022-05-10-enhanced-2fa-experience-for-your-npm-account/ https://github.blog/2022-05-10-enhanced-2fa-experience-for-y... It looks like the plan is to roll it out to any package with some amount of traction.
zackify 4y ago
The best part to all of this: If you generate a “CI Token” On npm. Anyone can still publish packages as you if they get ahold of it. No 2FA needed
- raggi 4y ago
  This. And this is the problem with signing too, in general. Signing is all well and good, but it doesn't do anything to demonstrate that the signed contents were prepared by a particular person. It only means they probably came from one of a set of computers. If they had adjusted to uploads require a hardware backed challenge pass, I'd be much more enthusiastic. Releases don't happen that often, adding a step to demonstrate presence to it would not be a huge burden.
- captn3m0 4y ago
  GitHub needs to implement OIDC auth for publishing workflows to NPM asap.
johnny_reilly 4y ago
I'm a top 500 package maintainer apparently (I think for my work on ts-loader but I'm not certain). This is great news. Some years ago an ethical hacker hacked me. I can still remember my shocked reaction upon being contacted by the hacker in question where I learned they now had the ability to publish malicious versions of npm packages on my behalf. This was long before supply chain attacks were well known and commonly discussed. A more innocent time. The hacker in question gave me a simple piece of advice: turn 2FA on for your packages. Which I subsequently did. It's great that npm are pushing this. Yes it's a faff but the tradeoffs are net good. A little inconvenience is reasonable as compared to the alternative possibility. I remain very grateful to the person who hacked me. If you should be out there: thanks - you did me a service
- GoblinSlayer 4y ago
  If you give your otp to a phishing site, it might not login again, but it can retain this session cookie for as long as it's valid and use it for access all that time.
  - Jnr 4y ago
    On https://github.com/settings/security https://github.com/settings/security you can revoke other sessions.
    - vladvasiliu 4y ago
      But you have to specifically go looking for this. GitHub doesn't notify you when you open a new session from an unknown browser.
  - totetsu 4y ago
    I'm always glad when the cookie I hard coded into my bash script curl command still works a year later.
- jimvdv 4y ago
  Do you use OTP codes? I recently switched to Yubikeys, find them to be much more convenient :)
ramesh31 4y ago
The rare phishing attack is hardly the danger with NPM. It's the implicit trust you put in some random person on the internet to not mess with your production code. The left-pad debacle was a benign beginning to what is now a full blown existential crisis for the JS community. There is so much incentive out there to compromise a package now, and so many packages, and so little oversight, that it's inevitable.
substack 4y ago
What happens when a developer can't publish a security update because they don't have 2FA enabled for a popular package? I was almost in this position. I don't have a phone, I don't have 2FA enabled and am not looking to do so. It seems like a 2FA mandate is going to ensure that people lose access to their accounts and won't be able to publish updates at all.
- HHC-Hunter 4y ago
  Have you guys paid Tim Dillon his Ransom yet?
- raverbashing 4y ago
  If your package can't be maintained someone who's willing to use 2FA will fork it and it will eventually be replaced as a dependency
- stickupkid 4y ago
  > I don't have a phone Get a yubikey[0], that way you don't need a phone. 0. https://www.yubico.com/products/ https://www.yubico.com/products/
  - kla999 4y ago
    I don't want a yubikey either. Hardware products are notorious for being subverted by agencies, honest companies can be bought by agency shell companies, etc. I find the recent push by big tech and others to discredit open software solutions like PGP suspicious. Banks push out new apps on a yearly basis, we are supposed to insert USB sticks to contribute to open source. Big tech rarely acts in your best interests.
- vladvasiliu 4y ago
  You don't need a phone to have multi-factor. You presumably have a PC if you're contributing to a package, so you can use a computer-based OTP generator, like Authy. Sure, if your computer gets owned, it won't help, but it's still much better than nothing and practically free.
vbezhenar 4y ago
May be I'm not aware but I never heard similar stories about Java libraries. Am I out of loop or is JS ecosystem differs from Java so much?
- deleted 4y ago
  [deleted]
Shadonototra 4y ago
identity verification (government issued id) + 2FA should be MENDATORY imo a move in the right direction also they should deny new IPs (other than different subnets) until real person verification

124 points by cute_boi 4y ago

Finally. NPM has been a security nightmare for too long.

I feel like there are still too many hands in this particular cookie jar. MFA or no. On average, how many other organizations & human developers are somehow involved in the dependency graph of a modern node.js project? I fail to see how MFA resolves the fundamental trust equation. Bad code is bad code, doesn't matter what the authentication system says about the actor's identity. I can create 2FA-enabled GH accounts all day named after JK Rowling characters without anyone at GH sending me a security nastygram or banning me for identity violations. Until GitHub requires government-issued photo ID in addition to MFA, I don't think you are going to properly discourage bad or criminal actors. To be clear: I strongly disagree with any notion that GitHub should require photo ID to open an account. But, perhaps a "verified user" option (extending to "verified org" if all users are compliant) might provide another path.

TAForObvReasons 4y ago
OpenSSF, which includes Google and Microsoft, has discussed real name verification requirements. That's definitely where the big money is pushing
yjftsjthsd-h 4y ago
> Until GitHub requires government-issued photo ID in addition to MFA, I don't think you are going to properly discourage bad or criminal actors. As a nice bonus, this is a great way to stop people from contributing to projects for free out of the goodness of their hearts. /s
- Aeolun 4y ago
  How so? I’m already contributing with an account that is astoundingly easy to resolve to my real name. Adding government issued ID to that equation would change nothing for me. I guess it might be problematic if you want to contribute to politically controversial stuff.
  - teddyh 4y ago
    This is the most literal version of “I have nothing to hide, so therefore neither does anyone else” I have seen in recent times.
    - Aeolun 4y ago
      Nowhere do I say that nobody has anything to hide. Hell, I have stuff to hide, but none of that is connected to my public Github account. I was simply challenging the assertation that contributions would dry up when required to identify yourself, and I don’t think that’s true. I can’t be the only one that has only a mildly pseudonymous account.
  - zorpner 4y ago
    Is the assertion here that people who have a troublesome family history, or a stalker, or debt, or who wish to change their lives, or are from a place where their social or racial group might be persecuted, or who simply wish to write code separately from their day-to-day, should not be allowed to do so?
  - yjftsjthsd-h 4y ago
    It's nice that you Have Nothing to Hide, but not everyone wants to - or can - live like that. It's not just politically sensitive stuff (though that's a good reason); some of us like having privacy, and there's no reason that we should have to give up our pseudonymity or anonymity in order to share our code with the world.
    - tomnipotent 4y ago
      An individuals anonymity does not take precedence over a professional supply chain that requires transparency, especially in the context of Top-N packages. The Linux kernel is one such example that does not accept anonymous contributions.
joekrill 4y ago
> I feel like there are still too many hands in this particular cookie jar. MFA or no. On average, how many other organizations & human developers are somehow involved in the dependency graph of a modern node.js project? What does that really matter, though? You could ask the same of _any_ modern application, NodeJS or otherwise: "On average, how many other organizations & human developers are somehow involved in the dependency graph of a modern application?". Look at your web browser alone. You have an open source rendering engine. The JavaScript engine. The underlying libraries used to handle things like SSL, TCP/IP, DNS lookups. It runs on an OS that likely has layers and layers of open source code. Which runs on hardware from various manufacturers with firmware written by many people spread across many organizations.
- Santosh83 4y ago
  The difference is people have become conditioned to trust corporations and organisations, so the software/hardware you mentioned have people or addresses who must answer if they get compromised. Whether they answer is a different thing, and whether this is a good model for everyone is another question. NPM packages on the other hand are dependent on random individuals for integrity and society doesn't trust individuals as much as registered entities, especially profit making ones.
rektide 4y ago
First, yes: there absolutely should be better tools for authors to sign & authenticate their own tools, with heightened cryptographic authentication means. Projects like sigstore get this (and wish to respect privacy![1]). But what's spoken of here is a deep imposition, and doesn't empower authors, but demands of them. > I fail to see how MFA resolves the fundamental trust equation Nothing ever will. Your desire for a cathedral is incompatible fundamentally & at every level with the bazaar. Trying to drive open-source society towards an industrialized security state for the convenience of your probably non-contributing, not-paying industrialized software production needs is vastly unfair. If you have needs, you need to take your own responsibility. If you have risks, you need to pay to hedge them. Go hire NodeSource to help you get the Certified Modules you can trust. Go sign contracts with authors to get the support you need. Heck, just checkin your package-lock.json and go see what you are downloading: npm is immutable! You could literally do anything to help safeguard yourself, but you ask for absolute protection, something that even the biggest best corporations can never truly promise. Trying to prevent even one reasonably placed malicious employee from causing disruption is a near impossible task. But you ask for a fundamental safety. This is laughable. None of us can expect nor deserve that. > Until GitHub requires government-issued photo ID in addition to MFA What a vile & fascist imposition this would be! Woe be unto us if industrialzied software so hotly presses for it's own security that it embraces such ludicrous & perverse a cowardice as this. Relying on github as your source of trust, and pressuring them to pressure the world into turning over core information, is just as antithetical as I can image to the open source behavior & society that has advanced us so far. What a terrible thing to wish for! Egads, gross. [1] https://blog.sigstore.dev/privacy-in-sigstore-57cac15af0d0 https://blog.sigstore.dev/privacy-in-sigstore-57cac15af0d0 https://news.ycombinator.com/item?id=31533997 https://news.ycombinator.com/item?id=31533997
- strawhatguy 4y ago
  Thank you for writing this; far too much entitlement, far too much blame shifting in the parent comment. Ultimately problems with your code, including deps it pulls in, are your problem, no one else's. Code appropriately.
  - 4y ago
doliveira 4y ago
Do we need to go this far? Why not just require a DNS which is what all of web security is centered around anyway? Most "serious" packages in Maven Central do have a dedicated DNS, for instance, even though there's the fallback of using io.github.username as the namespace. I feel like providing a namespace and starting to incentivize for it to correspond to a real DNS would be a good start.
grenran 4y ago
my69thaccount 4y ago
> Until GitHub requires government-issued photo ID in addition to MFA, I don't think you are going to properly discourage bad or criminal actors. To be clear: I strongly disagree with any notion that GitHub should require photo ID to open an account. But, perhaps a "verified user" option (extending to "verified org" if all users are compliant) might provide another path. this is absolutely dystopian. Please don't give microsoft any more ideas.
Gordonjcp 4y ago
Any government in particular? What about software developers that don't drive?
arinlen 4y ago
> Until GitHub requires government-issued photo ID in addition to MFA, I don't think you are going to properly discourage bad or criminal actors. This suggestion sounds like a way to create new and far bigger problems without doing anything to solve the original problem. Let's keep the problem in perspective, shall we? You want to freely access code contributed by someone over the internet, and you want to trust it's provenance. This does not change at all if you throw government-issued IDs into the mix, nor does this affect any of the attack vectors exploited by bad actors.

mrtweetyhack 4y ago

codedokode 4y ago

Sadly, 2FA won't help against malicious developer or a developer selling package to a malicious owner. Maybe ther should be a paid service that would manually review packages and provide a curated repository? I can't see other solutions. Either you review the code or you pay someone to do it or you isolate every library into a sandbox.

doliveira 4y ago
At the very least Maven-style DNS-based namespaces would be quite welcome... Then these authentication schemes or even "reputation" becomes DNS based which is much easier to do. Instead of having this random cutoff of popularity. I don't really get why all these package managers don't copy this from the Java world.

protomyth 4y ago

So, how exactly does this work for the random developer that somehow ends up in the top 500 but doesn't have 2FA turned on?

sheetjs 4y ago
Hi, random developer that somehow ended up in the top 500 but didn't have 2FA turned on (https://www.npmjs.com/package/xlsx https://www.npmjs.com/package/xlsx)! npm inc invalidated all of our authentication tokens in mid April and we have been unable to sign in via the web interface since then. Assumably the same fate befalls other random devs.
- smoldesu 4y ago
  Sounds like a pretty bad policy if that inhibits your ability to respond to critical security flaws in your package.
  - _ofdw 4y ago
    The npm ecosystem has been shown over and over again to be a dysfunctional tire fire. I feel like at this point continuing to publish on npm is kind of a "that's what you get" situation.
- protomyth 4y ago
  Did they tell your users that they locked out the developers? Uhm.... I kinda of expected some mediation or a step-by-step, but that just a dumpster fire solution.
- tedmiston 4y ago
  > npm inc invalidated all of our authentication tokens in mid April and we have been unable to sign in via the web interface since then This sucks, but invalidating the pre-2FA tokens is unavoidable if their goal is to tighten security of top packages. I don't know how this went down behind the scenes, but hopefully they announced giving you some long enough window like 60–90 days before the old tokens were invalidated. However, what does invalidating your old tokens have to do with signing into the web app that uses your username and password?

capableweb 4y ago

> Don't worry, if you want to automate publishing in CI/CD you can use an Automation Token to allow for publishing via token only without 2FA. From npm. Does this no longer apply? People can't publish from CI anymore as 2FA is now required?

seniorsassycat 4y ago
Tokens should still be allowed. Considering TOTP is just a shared secret there's no reason to requre it on top of tokens.

ashishbijlani 4y ago

Have they already enforced 2FA? The tool that I built to detect "risky" NPM/PyPI packages [1] still shows expired email domain for browserify (a top NPM package) 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj

oefrha 4y ago
Well, it’s probably only enforced if you submit a new version; can’t really disable a top package just because the author hasn’t logged in in a while. browerify was last updated two years ago and probably won’t see a new release ever, so the requirement doesn’t actually matter.
- Mathnerd314 4y ago
  Browserify had a PR merged on master in March for switching from non-ECMA String.substr to String.slice: https://github.com/browserify/browserify/pull/2036 https://github.com/browserify/browserify/pull/2036 Apparently it's too trivial for a release but the maintainers still seem to be around. Substack.net listed in package.json seems to be working: https://substack.net/cv.html https://substack.net/cv.html

throwaway0x7E6 4y ago

I can only recall a couple npm dramas where the developer had their account compromised. 9 times out of 10 the culprit is some leftpad tier dependency this ain't gonna do shit about Kony 2022 activism either, which is definitely going to be the next big thing

nsonha 4y ago

Why not just require it for all public packages?

abraham 4y ago
> The final cohort will be high-impact maintainers of packages with more than one million weekly downloads or 500 dependents later this year. https://github.blog/2022-05-10-enhanced-2fa-experience-for-your-npm-account/ https://github.blog/2022-05-10-enhanced-2fa-experience-for-y... It looks like the plan is to roll it out to any package with some amount of traction.

zackify 4y ago

The best part to all of this: If you generate a “CI Token” On npm. Anyone can still publish packages as you if they get ahold of it. No 2FA needed

raggi 4y ago
This. And this is the problem with signing too, in general. Signing is all well and good, but it doesn't do anything to demonstrate that the signed contents were prepared by a particular person. It only means they probably came from one of a set of computers. If they had adjusted to uploads require a hardware backed challenge pass, I'd be much more enthusiastic. Releases don't happen that often, adding a step to demonstrate presence to it would not be a huge burden.
captn3m0 4y ago
GitHub needs to implement OIDC auth for publishing workflows to NPM asap.

johnny_reilly 4y ago

I'm a top 500 package maintainer apparently (I think for my work on ts-loader but I'm not certain). This is great news. Some years ago an ethical hacker hacked me. I can still remember my shocked reaction upon being contacted by the hacker in question where I learned they now had the ability to publish malicious versions of npm packages on my behalf. This was long before supply chain attacks were well known and commonly discussed. A more innocent time. The hacker in question gave me a simple piece of advice: turn 2FA on for your packages. Which I subsequently did. It's great that npm are pushing this. Yes it's a faff but the tradeoffs are net good. A little inconvenience is reasonable as compared to the alternative possibility. I remain very grateful to the person who hacked me. If you should be out there: thanks - you did me a service

GoblinSlayer 4y ago
If you give your otp to a phishing site, it might not login again, but it can retain this session cookie for as long as it's valid and use it for access all that time.
- Jnr 4y ago
  On https://github.com/settings/security https://github.com/settings/security you can revoke other sessions.
  - vladvasiliu 4y ago
    But you have to specifically go looking for this. GitHub doesn't notify you when you open a new session from an unknown browser.
- totetsu 4y ago
  I'm always glad when the cookie I hard coded into my bash script curl command still works a year later.
jimvdv 4y ago
Do you use OTP codes? I recently switched to Yubikeys, find them to be much more convenient :)

ramesh31 4y ago

The rare phishing attack is hardly the danger with NPM. It's the implicit trust you put in some random person on the internet to not mess with your production code. The left-pad debacle was a benign beginning to what is now a full blown existential crisis for the JS community. There is so much incentive out there to compromise a package now, and so many packages, and so little oversight, that it's inevitable.

substack 4y ago

What happens when a developer can't publish a security update because they don't have 2FA enabled for a popular package? I was almost in this position. I don't have a phone, I don't have 2FA enabled and am not looking to do so. It seems like a 2FA mandate is going to ensure that people lose access to their accounts and won't be able to publish updates at all.

HHC-Hunter 4y ago
Have you guys paid Tim Dillon his Ransom yet?
raverbashing 4y ago
If your package can't be maintained someone who's willing to use 2FA will fork it and it will eventually be replaced as a dependency
stickupkid 4y ago
> I don't have a phone Get a yubikey[0], that way you don't need a phone. 0. https://www.yubico.com/products/ https://www.yubico.com/products/
- kla999 4y ago
  I don't want a yubikey either. Hardware products are notorious for being subverted by agencies, honest companies can be bought by agency shell companies, etc. I find the recent push by big tech and others to discredit open software solutions like PGP suspicious. Banks push out new apps on a yearly basis, we are supposed to insert USB sticks to contribute to open source. Big tech rarely acts in your best interests.
vladvasiliu 4y ago
You don't need a phone to have multi-factor. You presumably have a PC if you're contributing to a package, so you can use a computer-based OTP generator, like Authy. Sure, if your computer gets owned, it won't help, but it's still much better than nothing and practically free.

vbezhenar 4y ago

May be I'm not aware but I never heard similar stories about Java libraries. Am I out of loop or is JS ecosystem differs from Java so much?

deleted 4y ago
[deleted]

Shadonototra 4y ago

identity verification (government issued id) + 2FA should be MENDATORY imo a move in the right direction also they should deny new IPs (other than different subnets) until real person verification