[paustint]

In this case, the author's NPM account was taken over, email address changed to one the attacker controls, and the package was manually published.

Since the attacker had full control of the NPM account, it is game over - the attacker can login to NPM and could, if they wanted, configure Trusted Publishing on any repo they control.

Axios IS using trusted publishing, but that didn't do anything to prevent the attack since the entire NPM account was taken over and config can be modified to allow publishing using a token.

[staticassertion]

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).

[efilife]

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

[staticassertion]

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

[erikerikson]

Instead they took away TOTP as a factor.

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

[mayhemducks]

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

[staticassertion]

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.

[erikerikson]

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

[moebrowne]

TOTP isn't phishing resistant

[erikerikson]

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

[staticassertion]

It's not much better than nothing. It basically solves "I reused my password across sites" exclusively, that's it. If you're going to go through the effort of TOTP, it seems odd that you wouldn't just use a unique password.

If you use a unique password it's questionable if it adds any value at all. Perhaps in very niche situations like "password authentication is itself vulnerable due to a timing attack/ bug" or some such thing... but we've rarely seen that in the wild.

[erikerikson]

I disagree.

I use a password manager and systemically use long random passwords. An attacker would need to compromise my password manager, phish me, wrench me, or compromise the site the credential is associated with to get that.

Using local only TOTP (no cloud storage or portability for me, by choice) they would have to additionally phish me, wrench me, compromise my phone, or compromise my physical security to get the code.

None of these are easy except the wrench which is high risk. My password manager had standard features which make me more phishing resistant, and together they are more challenging than either apart. For example the fact that my password manager will not fill in the password on a non associated site means I am much less likely to fill in a TOTP code on an inappropriate site. Though there are vulnerable scenarios they aren't statistically relevant in the wild and the bar is higher regardless.

Now I happen to have a FIDO key which I use for my higher security contexts but I'm a fairly low value target and npm isn't one of my high security contexts. TOTP improves my security stance generally and removing it from npmjs.org weakened my security stance there.

[staticassertion]

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

[dboreham]

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.

[woodruffw]

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.