I have a hard time arguing that 2FA isn't a massive win in almost every circumstance. Having a "confirm that you have uploaded a new package" thing as the default seems good! Someone like npm mandating that a human being presses a button with a recaptcha for any package downloaded by more than X times per week just feels almost mandatory at this point.

The attacks are still possible, but they're not going to be nearly as easy here.

▲

SchemaLoad 3 days ago | parent [-]

2FA is a huge benefit over plain passwords. But it wasn't enough here. The package dev had 2FA and it did not help since they got tricked in to logging in to a phishing page which proxied the 2FA code to the real login page.

▲

bbarnett 3 days ago | parent [-]

Yet the parent said for each upload prior to publish.

This attack would have 100% been thwarted, when a load of emails appeared saying "publish package you just uploaded?".

(if you read the dev's account of this, you'll see this would have worked)

▲

mnahkies 3 days ago | parent | next [-]

Another advantage of this would be for CI/CD - MFA can be a pain for this.

If I could have a publish token / oidc Auth in CI that required an additional manual approve in the web UI before it was actually published I could imagine this working well.

It would help reduce risk from CI system breaches as well.

There are already "package published" notification emails, it's just at that point it's too late.

	▲	const_cast 3 days ago \| parent [-]
		Yes, exactly. A lot of these 2FA schemes or attestation schemes break automation, which is really undesirable in this particular scenario. Its tricky.

▲

hvb2 3 days ago | parent | prev [-]

Assuming you've compromised said developers account, wouldn't you be able to click that publish button too?