MFA and security enforcement

Debate over whether npm should mandate hardware keys or phishing-resistant 2FA for popular package maintainers, and how to handle CI/CD publishing

The debate centers on whether npm should mandate phishing-resistant hardware keys for popular maintainers, with many arguing that traditional TOTP is an obsolete defense against modern supply chain attacks. While proponents suggest scaling security requirements alongside a package’s popularity through multi-signature approvals and cooling-off periods for account changes, others caution that manual verification can become a "velocity blocker" that developers will inevitably bypass. To resolve the tension between automation and security, participants advocate for "Trusted Publishing" models and cryptographic attestations that verify releases directly from source code rather than relying on potentially compromised long-lived tokens. Ultimately, the consensus highlights a need for the ecosystem to shift from simple password-based discipline toward more robust, hardware-backed primitives that protect the integrity of the software supply chain.

View on HN · Topics

Batteries included systems are still susceptible to supply chain attacks, they just move slower so it’s not as attractive of a target.

I think packages of a certain size need to be held to higher standards by the repositories.
Multiple users should have to approve changes. Maybe enforced scans (though with trivy’s recent compromise that wont be likely any time soon)

Basically anything besides lone developer can decide to send something out on a whim that will run on millions of machines.

View on HN · Topics

Yeah, NPM should be enforcing 2FA and likely phishing resistant 2FA for some packages/ this should be a real control, issuing public audit events for email address changes, and publish events should include information how it was published (trusted publishing, manual publish, etc).

View on HN · Topics

https://docs.npmjs.com/configuring-two-factor-authentication

> Important: Publishing to npm requires either:
Two-factor authentication (2FA) enabled on your account, OR
A granular access token with bypass 2FA enabled

View on HN · Topics

I'm assuming the author must have been grandfathered in to TOTP?

View on HN · Topics

Instead they took away TOTP as a factor.

Scaling security with the popularity of a repo does seem like a good idea.

View on HN · Topics

Are there downsides to doing this? This was my first thought - though I also recognize that first thoughts are often naive.

View on HN · Topics

You don't want "project had X users so it's less safe" to suddenly transition into "now this software has X*10 users so it has to change things", it's disruptive.

View on HN · Topics

TOTP although venerable was better than no second factor at all.

View on HN · Topics

TOTP isn't phishing resistant

View on HN · Topics

No it's not but it's better than nothing. Don't let the perfect be the enemy of the good.

View on HN · Topics

It's not much better than nothing. It basically solves "I reused my password across sites" exclusively, that's it. If you use a unique password it's questionable if it adds any value at all.

View on HN · Topics

TOTP seems effectively useless for npm so that seems fine to me

View on HN · Topics

Well, that sucks! It’ll be interesting to learn how they obtained a valid second factor or 2FA bypass; that will inform the next round of defenses here.

View on HN · Topics

One wonders if Microsoft/npm.js should allow new packages to be published immediately following an account email address change? I mean changes to email address are already recognized as potential attack vectors, so emails are sent to the old address warning of potential account take over. But this seems to have been done at night, so the warning email would not be seen yet. Even so a new package could be published and served to the world immediately. Unless I misunderstand something about the facts this would indicate an extreme lack of imagination in the people at Microsoft who already went through several cycles of hardening the service against supply chain poisoning attacks.

View on HN · Topics

I don’t know what this means. Discipline is good, but I think you need to have good tools/primitives in place to help people exercise discipline.

(The classic example being passwords: we wouldn’t need MFA is everybody just “got good” and used strong/unique passwords everywhere. But that’s manifestly unrealistic, so instead we use our discipline budget on getting people to use password managers and phishing-resistant MFA.)

View on HN · Topics

Really? You don't know the difference between having a door lock, and using it?

MFA is typically enforced by organizations, forcing discipline. Individual usage of MFA is dramatically lower

View on HN · Topics

It's so your private key is not stolen, but you're right passphrase protected keys win anyway. I use hardware keys so this isn't a problem for me to begin with.

View on HN · Topics

If the fat std library is not viable you can only increase security requirements.

Axios has like 100M downloads per week. A couple of people with MFA should have to approve changes before it gets published.

View on HN · Topics

This is the actual answer: stupid cost saving creating an operational risk.

View on HN · Topics

At least then they will have to pay off a dev or something, changes their economic calculus and is additionally illegal

View on HN · Topics

They're not a failed experiment. No one has ever "experimented" by making a safe package manager for their new language. And it is not that insane to do so. Very basic things will get you very far:

Packages should carry a manifest that declares what they do at build time, just like Chrome extensions do. This manifest would then be used to configure its build environment.

Publishers to official registries should be forced to use 2FA. I proposed this a decade ago for crates.io and people lost their minds, like I was suggesting we drag developers to a shed to be shot.

Every package registry should produce a detailed audit log that contains a "who, what, when". Every build/ command should be producing audit logs that can be collected by endpoint agents too.

Every package registry should support TUF.

Typosquatting defenses should be standard.

etc etc etc. Some of this is hard, some of this is not hard. All of this is possible. No one has done it, so it's way too early to say "package managers can't be made safe" when no one has tried .

View on HN · Topics

Love these ideas!

View on HN · Topics

> Publishers to official registries should be forced to use 2FA. I proposed this a decade ago for crates.io and people lost their minds, like I was suggesting we drag developers to a shed to be shot.

How is this enforced when it's pushed via a pipeline?

View on HN · Topics

Your account is separate from your publishing. That is, in order to go to my account to change configuration values, 2FA must be required.

Publishing should be handled via something like Trusted Publishing, which would leverage short lived tokens and can integrate with cryptographic logs for publish information (ie: "Published from the main branch of this repo at this time").

View on HN · Topics

This may not be popular, but is there a place for required human actions or just timed actions to slow down things like this? For instance, maybe a GH action to deploy requires a final human click and to change that to cli has a 3 day cooling period with mandatory security emails sent out. Similarly, you switch to read only for 6 hrs after an email change. There are holes in these ideas but the basic concept is to treat security more like physical security, your goal isn't always to 100% block but instead to slow an attacker for xxx minutes to give the rest of the team time to figure out what is going on.

View on HN · Topics

Hi, security here. We've tried, but the amount of people you need for this vs the amount of people you have trying to review and click the big button always means that this step will be a bottleneck. Thus this step will be eliminated.

A much better approach would be to pin the versions used and do intentional updates some time after release, say a sprint after.

View on HN · Topics

Pinning, escrowing, and trailing all help, but I'm not sure "this step will be eliminated" is inevitable.

Package manager ecosystems are highly centralized. npm.org could require MFA (or rate limit, or email verification, or whatever) and most packagers would gripe but go along with this. A minority would look for npm competitors that didn't have this requirement, and another minority would hack/automate MFA and remove the added security, but the majority of folks would benefit from a centralized requirement of this sort.

View on HN · Topics

Let me rephrase - manual security verification is a velocity blocker. People won't do manual security verification of changes.

I agree that npm.org requiring MFA is a good idea in general and in this case.

View on HN · Topics

Yup. As someone who's been on both the eng and security side, you cannot improve security by blocking the product bus. You're just going to get run over. Your job is to find ways of managing risk that work with the realities of software development.

And before anyone gets upset about that, every engineering discipline has these kind of risk tradeoffs. You can't build a bridge that'll last 5,000 years and costs half of our GDP, even though that's "safer". You build a bridge that balances usage, the environment, and good stewardship of taxpayer money.

View on HN · Topics

There's a package manager discussion, but the bit that stands out to me is that this started with a credential compromise. At some point when a project gets big enough like axios, maybe the community could chip in to buy the authors a couple of YubiHSM or similar. I wish that _important keys live in hardware_ becomes more standard given the stakes.

Dealing with dependencies is another question; if it's stupid stuff like leftpad then it should be either vendored in or promoted to be a language feature anyway (as it has been).

View on HN · Topics

> At some point when a project gets big enough like axios, maybe the community could chip in to buy the authors a couple of YubiHSM or similar

I kind of feel like the authors here should want that for themselves, before the community would even realize it's needed. I can't say I've worked on packages that are as popular as axios, but once some packages we were publishing hit 10K downloads or so, we all agreed that we needed to up our security posture, and we all got hardware keys for 2FA and spent 1-2 weeks on making sure it was as bullet-proof we could make it.

To be fair, most FOSS is developed by volunteers so I understand not wanting to spend any money on something you provide for free, but on the other hand, I personally wouldn't feel comfortable being responsible for something that popular without hardening my own setup as much as I could, even if it means stopping everything for a week.

View on HN · Topics

I thought npm started requiring hardware keys for publish, or may have been new accounts only

View on HN · Topics

Totally agree.

Also, considering how prevalent TPM/Secure Enclaves are on modern devices, I would guess most package maintainers already have hardware capable of generating/using signing keys that never leave hardware.

I think it is mostly a devex/workflow question.

Considering the recent ci/cd-pipeline compromises, I think it would make sense to make a two phase commit process required for popular packages. Build and upload to the registry from a pipeline, but require a signature from a hardware resident key before making the package available.

View on HN · Topics

I'm working on a multi signature solution that helps to detect unauthorized releases in the case of an account hijack. It is open source, self hostable, accountless and I am looking for feedback!

Website: https://asfaload.com/

GitHub: https://github.com/asfaload/asfaload

Spec: https://github.com/asfaload/spec

View on HN · Topics

That's a good point. In some level I'd prefer the delay to happen on publication of the package itself. Do any of these scanners have cryptographic attestations or similar?

View on HN · Topics

Many of the suggestions in this thread (min-release, ignore script) are defenses for the consumers.

I've been working on Proof of Resilience, a set of 4 metrics for OSS, and using that as a scoring oracle for what to fund.

Popularity metrics like downloads, stars, etc are easy to fake today with ai agents. An interesting property is that gaming these metrics produces better code, not worse.

These are the 4 metrics:

1. Build determinism - does the published artifact match a reproducible build from source?

2. Fuzzing survival - does the package survive fuzz testing?

3. Downstream stability - does it break any repos dependent on this project when pushing a release?

4. Patch velocity - how fast are fixes merged?

Here's a link to the post, still early but would appreciate any feedback.

https://hackmd.io/@carlb/proof-of-resilience

View on HN · Topics

How is it we've made it this far and we still don't have any kind of independent auditing of basic publish security on NPM? You'd think this would be collectively a trivial and high priority task (to ensure that all publishes for packages over a certain download volume are going through a session that authenticated via MFA, for instance).

View on HN · Topics

> You'd think this would be collectively a trivial and high priority task (to ensure that all publishes for packages over a certain download volume are going through a session that authenticated via MFA, for instance).

Because all mainstream packages are published via CI/CD pipeline not by an MFA'd individual uploading a GZIP to npm.com

View on HN · Topics

Requiring a human-in-the-loop for final, non-prerelease publication doesn't seem like that onerous of a burden. Even if you're publishing multiple releases a day on the regular (in which case ... I have questions, but anyway) there are all sorts of automations that stay secure while reducing the burden of having to manually download an artifact from CI, enter MFA, and upload it by hand.

View on HN · Topics

You can still have a step that requires a certain user/group to sign off, and you can still enforce that those users have MFA set up. Almost any serious shop that expects to pass audits already does this in some form or fashion before pushing code to prod.

View on HN · Topics

> Both versions were published using the compromised npm credentials of a lead axios maintainer, bypassing the project's normal GitHub Actions CI/CD pipeline.

Doesn’t npm mandate 2FA as of some time last year? How was that bypassed?

View on HN · Topics

Apparently it's possible to create access tokens that bypass 2FA. Might've been this.

https://docs.npmjs.com/creating-and-viewing-access-tokens

View on HN · Topics

So the root cause was again a developer's opsec. For improving things, I haven't seen many new initiatives on that side (beyond 2FA, but even that seems unenforced in these repositories, I reckon).

View on HN · Topics

Please can we just have a 2FA step on publishing? Do we really need a release to be entirely and fully automated?

It won't stop all attacks but definitely would stop some of these

View on HN · Topics

npm really needs to provide a options to set individual packages to only be publishable via trusted publishing.

Summarizer