2FA on publish

[mbarnathan]

Given the number of credential stealing worms currently spreading through the ecosystem, has the community considered password protecting tokens at the time of publication, much like SSH keys are encrypted with a password? Adding a "what you know" second factor to the "what you have" key would prevent propagation via exfiltration.

[ghostdevv]

Part of the problem is that we run publishing through CI, and need to for trusted publishing/provenance. Something that occured to me the other day is that we could allow publishing, but a published package wouldn't go "live" until you confirm it in the dashboard either with a "something you know", or with something like a fingerprint/yubikey backed passkey.

[ljharb]

You don't actually need provenance - it's useless and adds no value.

[ghostdevv]

You don't actually need provenance - it's useless and adds no value.

It feels increasingly valuable to be able to show when and where something was built. We can have a direct link from the source code, to the final output we're actually downloading. This is one step towards a more secure npm, as we can see exactly where it was published, which is one indication that something may have been compromised. For example, if an attacker gets access to my machine and is able to publish a package, then any package that I had previously published with provenance will have a "trust downgrade", which is a signal that something has gone wrong. Now of course that isn't a silver bullet, as we've seen recently attacks effecting CI can get code published while provenance is happy, and for that we need other signals or protections. Like with everything we're doing to improve security, it's one piece of the puzzle but doesn't solve the entire thing.

In excellent timing, npm today has released staged publishing which is another step in the right direction. I'm not sure of how it's implemented yet, so it could be missing some stuff but assuming it's not - This can help prevent against issues of CI attacks as now an attacker would also need to breach the login details and 2fa of someone with publishing rights, in order to be able to approve a build. This hopefully can be taken further to allow maintainers to force the requirement of a hardware/fingerprint passkey, which would mean an attacker would have to literally attack someone in order to publish.

All of this stuff is increasing in importance as LLMs increase the speed at which attacks can happen, and is especially important for maintainers such as yourself who maintain a lot of popular packages. Human mistakes will still happen, but the surface area for attackers is massively decreased if adopt all these practises going forward and hopefully together supply chain attacks can go back to being few and far between.

Anything I missed? 😅 /genq

[ljharb]

We can have a direct link from the source code, to the final output we're actually downloading

No, this is just a direct link from a CI workflow to the registry - that doesn't actually tell you what the final output is.

There is not a single incident that has ever occurred that provenance would have helped to prevent, so it's not just "not a silver bullet", it's of no value at all.

Staged publishing is absolutely a massive improvement, and if npm had shipped it 5 years ago, shai hulud wouldn't have been possible. Provenance isn't relevant here.

[ghostdevv]

No, this is just a direct link from a CI workflow to the registry - that doesn't actually tell you what the final output is.

Right, it tells proves what the source code was

There is not a single incident that has ever occurred that provenance would have helped to prevent, so it's not just "not a silver bullet", it's of no value at all.

If someone got access to my computer and published a new version of a package with malware, and the previous versions were all published with provenance, then any consumers of the package who's package managers fail on a "trust downgrade" will not install the malware.

Staged publishing would only protect against the few recent examples of Mini Shai-Hulud that were published because CI was attacked. In that case CI only has permission to publish new versions of the package, and so staged publishing adds the second layer that successfully mitigates the attacks. Sure, it'd also protect if they somehow got access to my account and had one 2fa code, not two. However, if they do get access to my 2fa then staged publishing is useless, as they can just accept the publish. This is where provenance would be another layer of protection, as they would have to somehow get access to my account details, 2fa, and CI.

[ljharb]

Ceasing use of provenance is a legitimate maintainer decision - not a "trust downgrade".

In the recent axios attack, they had the maintainer's accounts - so they could publish malware with provenance attached. Provenance changes in either direction are simply a non-signal.

Almost every incident in the last couple years was a result of CI being attacked. If they have your account, NOTHING stops them - no technical means exists to stop them at that point.

[said3791]

Hi everyone,

I'm locked out of my GitHub account

I lost my phone which had the GitHub Mobile app as my only 2FA method.
I enabled 2FA in November 2024 and I'm not sure I saved my recovery codes.

Has anyone been in this situation and found a way to recover their account?

Any help is appreciated. Thank you!