Why is npm getting rid of TOTP as 2FA authentication method?

[prahladyeri]

Select Topic Area

Question

Body

I've been aghast to know that npm is now phasing out TOTP as a legitimate 2FA method of authentication and replacing it with more intrusive and authoritarian methods like FIDO and Webauthn.

It's a bit perplexing that an organization that apparently stands up for Open Source as a way of life would introduce such a closed and walled garden approach of authentication which may not be accessible to everyone. Those on Linux Desktops such as Mint or Fedora, or those using an open source browser like Firefox, may not have access to these chosen new 2FA methods.

I'd also like to know what exactly is the issue with TOTP as an authentication system, what do the proponents of this new system think is wrong with it?

[gunavardhangolagani]

Hi @prahladyeri ,

The main reason npm is phasing out TOTP is security.
TOTP codes can still be phished or relayed in real time, and the shared secret can be stolen if your device is compromised. Recent supply-chain attacks on npm maintainers showed that even users with TOTP 2FA could be tricked into giving up their codes.

FIDO/WebAuthn (like hardware keys or passkeys) are phishing-resistant the private key never leaves your device and authentication is bound to the site’s domain, so it can’t be reused elsewhere.

That said, many developers share your concern about accessibility especially those on Linux or open-source browsers.
GitHub has said they’re working to improve cross-platform support, but for now FIDO/WebAuthn is considered the most secure option available.

[prahladyeri]

Thanks for the response.

TOTP codes can still be phished or relayed in real time

While this is true, it can be said about any kind of credential including emails and passwords, security codes, API tokens, OTPs, etc. Shouldn't it be the responsibility of a package maintainer or developer to ensure their own device security and not fall for phishing scams?

At most, NPM could suggest or recommend FIDO/WebAuthn while setting up the 2FA methods but having an all or none approach and removing TOTP option entirely seems going too far.

[vindicatorr]

Recent supply-chain attacks on npm maintainers showed that even users with TOTP 2FA could be tricked into giving up their codes.

Looks like they could then be tricked into giving up their passkey private key as well. POC with keepass allowing me to export the passkey, and I see the data in JSON with "privateKey".

private key never leaves your device and authentication is bound to the site’s domain, so it can’t be reused elsewhere.

Is the TOTP code not bound to the domain? They are the ones that issued it, no?

[3nprob]

FYI:

There is a community thread for this topic here: https://github.com/orgs/community/discussions/174505 (consider upvoting)

GitHub recently posted an update on their plans here: https://github.com/orgs/community/discussions/178140

[LeonMueller-OneAndOnly]

That the only 2FA method npm provides to users now are hardware keys is a HUGE security issue and achieves the opposite of the intended effect. Way fewer people are willing to use that...

[consoleillusion]

Yes. I will not use npm registry as long as this is the case. I wonder if NPM has heard of SSH or RSA keys?

[Yan-Santana]

That the only 2FA method npm provides to users now are hardware keys is a HUGE security issue and achieves the opposite of the intended effect. Way fewer people are willing to use that...

[Guten-Morgen1302]

Thanks for the question! npm is moving away from TOTP primarily due to security concerns and not because of any preference toward proprietary or “closed” systems.

TOTP codes can be phished or intercepted, especially during targeted supply-chain attacks. Attackers can trick users into entering their one-time codes on fake sites, or capture them in real time and immediately reuse them. For a large package ecosystem like npm, this risk is significant because account compromise can lead to widespread malicious package publication.

FIDO/WebAuthn-based 2FA provides strong protection against these attacks. These methods are phishing-resistant, since authentication is bound to the legitimate domain and the private key never leaves the user’s device. This is why many ecosystems (npm, GitHub, Google, GitLab, etc.) are standardizing around them.

Regarding accessibility:
WebAuthn support has expanded widely — Linux distributions and Firefox do support hardware keys and WebAuthn flows, but some setups may require additional configuration. npm is continuing to improve support and documentation for these environments.

To summarize:

Why phase out TOTP? It’s still better than nothing, but it’s vulnerable to phishing and real-time interception.

Why WebAuthn/FIDO? They are phishing-resistant, more secure for a large software registry, and now broadly supported across platforms.

Accessibility? The shift isn’t intended to exclude users; compatibility on Linux and open-source browsers is supported and continually improving.

Hope this helps clarify the reasoning behind the transition!

[LeonMueller-OneAndOnly]

Thank for the detailed answer. I agree with you that WebAuthn "Passkeys" provide stronger protection against phishing. But they are less adopted by users, especially in teams / organisations. Since sharing them is hard / not natively supported and therefore always leads to huge friction when wanting to share a master account, like one would typically do with NPM.

With the raising popularitry of NPM worms like Shai-Hulud 1 & 2 (https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack), the only effective solution forward is going to be to enforce / heavily recommend 2FA.

Blocking people from using a 2FA solution that they know & that works for them in their professional settings, is a very bad idea and i want to advocate strongly against it.

Encourage users to use these WebAuthn-Keys, but leave an option for classic TOTP-tokens.

My whole concern can be summarized by this:

P(phishing ∣ already uses 2FA) << P(no 2FA usage due to restrictions)

[brandon-fryslie]

Passkeys in practice have significant usability issues. I've migrated away from them until there's some improvements.

All of the 'keys can't leave the device' stuff sounds (maybe) reasonable to someone designing a spec. But here's the root problem. If you must tie every key to a device and it can't leave that device, the keys cannot survive the loss of that device. Am I supposed to enroll every device I own in 2FA on NPM, one-by-one? Have a pristine 'break-in-case-of-emergency' device that I enroll whenever I create a new user account somewhere? Putting users in a position where losing their personal phone or having a laptop die might lock them out of critical accounts, possibly permanently, just isn't reasonable. At work, yes, but not for my own personal stuff. This theoretical perfect security situation is not generalizable and no one would use it. So of course you CAN export the keys.

And once keys can leave the device all bets are off. I can export them from 1password trivially. And so could someone with access to my device and my password manager credentials. It's harder to phish than TOPT, yes, but someone who's reading those codes over the phone after hearing a million times to never do that under any circumstance will probably find a way.

I would recommend reconsidering this decision. I'm not sure what the right answer is. But I guess until you guys figure that out, I'll make sure I use the longest password you support and get a code over email.

[embedding-shapes]

It's a bit perplexing that an organization that apparently stands up for Open Source

Where in the world are you getting this from? NPM is a project run and maintained by Microsoft, famous anti-FOSS company, not sure why you'd believe otherwise.

[turkeii1337]

push

[cha0s]

Can't believe I just got locked out of my NPM 2FA after disabling my current TOTP (bc I am setting up a diffferent, LOCAL, SECURE TOTP) instance after relying on 3rd parties for so long.

I guess now my account has no security whatsoever.

I guess I'm never publishing to npm again.

EDIT: OR hey, maybe I am! Since you reduced the security of my account I now can't be held liable for anyone taking control and publishing whatever. Brilliant, boys.

[AbhishekKTech]

Hey! I completely understand why this is frustrating, but there's actually a very good security reason for the change.

To answer your overall question about what's wrong with TOTP: The main problem with TOTP is that 6-digit codes are susceptible to phishing attacks. If a phishing site for npm asks for your code, hackers can immediately steal it and take over your packages. FIDO and WebAuthn solve this entirely because they check the domain of the actual website. A phishing site can't steal your login.

Also, don't worry about the "walled garden" issue! FIDO and WebAuthn are actually open web standards (W3C), not controlled by any one company.

They also support Linux and Firefox. You don't need a Macbook or Windows Hello to use them. You can simply use:

A USB security key (there are even open-source ones like SoloKeys).

A cross-platform password manager like Bitwarden, which supports passkeys directly in the Firefox browser.

Hope this clears things up!

[LeonMueller-OneAndOnly]

These passkeys are very hard to share in a team context. Which leads to people working in teams (as most professionals do in a business context) not using them. Which in turn leads to many developers not using 2FA at all. This is definitely not more secure, it is a bad design decision security wise. Nude your users to use Passkeys, but provide an escape hedge for professionals.

[AbhishekKTech]

Hey, @LeonMueller-OneAndOnly Although it is inconvenient, teams shouldn't be sharing a single NPM account in the first place.

Here, establishing a npm organization is the standard course of action. You simply give each team member read/write access to the company's packages, and they each use their own personal account (with their own passkey).

Granular Access Tokens or Trusted Publishing (OIDC) are the best options if you require shared access for automated scripts or CI/CD pipelines. These completely avoid the 2FA prompts.

The issue has been resolved without sacrificing security!

[vishwateja231]

I get both sides here to be honest. From a security point of view, passkeys and individual accounts definitely make sense, especially considering how common phishing attacks have become. At the same time, in real teams the friction is real too—changing workflows, setting up organizations, managing tokens, ’s not hard but it does take time and some teams are slow to adapt. I’ve seen cases where people avoid enabling security features simply because the setup feels complicated, which kind of defeats the purpose.

Maybe the real issue isn’t the technology itself but how smoothly teams can transition to it. If the tooling and documentation make setting up organizations, tokens, and CI access really straightforward, most teams will naturally move away from shared accounts anyway. Security usually works best when the secure option is also the easiest one to follow.

[LeonMueller-OneAndOnly]

@AbhishekKTech

The complexity is the issue.

For simple use cases in small companies or teams, a security‑minded developer used to just set up TOTP - and distribute + back up the QR code.

Now that this is no longer possible, and instead accounts have to be created for everyone - the developer himself, his teammates, his manager, the CEO, and so on — it turns into an “initiative” that will never actually get done.

In theory, passkeys are great. In reality, they lack accessibility. And accessibility is the most important security aspect: even the strongest lock won’t protect your bike if it’s too annoying to use.

[quinndiggitypolymath]

So, what you are saying is that Bitwarden is secure enough to store one form of secret key material, but it also isn't secure enough to store secret key material, because those secrets could be stolen or people could be socially engineered into providing them - @AbhishekKTech , am I correct in understanding that you have no idea what you are talking about?

[quinndiggitypolymath]

Just wanted to thank @AbhishekKTech , @Guten-Morgen1302 , @gunavardhangolagani , and the other goons @ microsoft, for helping extinguish another microsoft product - it would have been nice if you didn't go out of your way to destroy a community, and force everyone to repair bridges and build entirely new communities to replace the one you destroyed, but at least you are being overt enough that everyone is leaving. Next time, just build your own thing, let it fail, instead of buying something pre-established and killing that - there's plenty of benign things of your own you can kill off, if you find that sort of behaviour to be necessary for whatever reason.

[AbhishekKTech]

Hey guys, fair points all around.

@LeonMueller-OneAndOnly I completely agree that the friction for small teams is a pain. Setting up an organization is definitely more annoying than just sharing a TOTP QR code. It is a strict trade-off of convenience for security, and I get why that is frustrating.

@quinndiggitypolymath To clarify the Bitwarden thing: the issue has nothing to do with Bitwarden being insecure. The vulnerability with TOTP is that a human can be tricked into typing that 6-digit code into a fake phishing site.

Passkeys fix this because they are cryptographically tied to the actual website domain. Even if your passkey is stored in Bitwarden, the browser physically will not let you authenticate on a fake, lookalike npm login page. It completely removes the human error part of phishing.

Just sharing the technical reason behind the shift!

https://youtu.be/M_W-dleZXCs

This highlights the exact kind of devastating ecosystem compromises that forced npm to make these drastic, strict security changes in the first place.