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).
> Important: Publishing to npm requires either:
Two-factor authentication (2FA) enabled on your account, OR
A granular access token with bypass 2FA enabled
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.
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.
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.
My password manager, as is standard for most of them, will not fill or show a password if the URL bring visited doesn't match the credential. Thus, a credential not showing is a huge red flag. The workflow is pretty standardized so any deviation is a big red flag.
Maybe you can be more specific about the attack flow you are imagining and how it will work technically to bypass my controls.
To answer your question, no and I provided details. It literally provides a second, non portable factor with a different vulnerability surface.
> My password manager, as is standard for most of them, will not fill or show a password if the URL bring visited doesn't match the credential. Thus, a credential not showing is a huge red flag. The workflow is pretty standardized so any deviation is a big red flag.
I agree.
> Maybe you can be more specific about the attack flow you are imagining and how it will work technically to bypass my controls.
Can you be more specific about the attack that your password manager doesn't solve that your TOTP does? The attack I'm suggesting is already solved by your password manager.
I've believe I've already written that but it is that my password manager gets compromised. It is not perfectly secure and has failure points. Given that it is separate from the second factor a successful attack against the password manager still leaves an attacker unable to login without a separate compromise of my TOTP code. Of course that can also be compromised but two compromises is strictly more difficult than one.
Right, so it's "password manager is compromised" or "password is reused", right? I'm pretty skeptical of these mattering relative to phishing, which is radically more common.
