GitHub Community
Why is npm getting rid of TOTP as 2FA authentication method? #178148
Replies: 22 comments 22 replies
|
Hi @prahladyeri , The main reason npm is phasing out TOTP is security. 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. |
|
Thanks for the response.
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. |
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
Is the TOTP code not bound to the domain? They are the ones that issued it, no? |
Thereʼs no mechanism for that; it really is a weakness in the protocol. Suppose Iʼm an attacker. I send you an email and convince you to try to log into notreallynpmjs.com. You enter your username and password. On the backend, notreallynpmjs.com tries to log in with your credentials to npmjs.com and sees it needs a TOTP code, so notreallynpmjs.com asks you for one. You then go to wherever you generate TOTPs, which is usually an app on your phone. It tells you six digits for npmjs.com, which you then enter into notreallynpmjs.com; nothing except you can check that youʼre on the right site. Nothing but you can verify that you are on the right site, and if we assume the phishing attack got your password, you already failed at that step. That said, disabling TOTP when the alternatives do not adequately replace the use cases was a terrible move. |
|
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 |
|
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... |
|
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? |
|
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... |
|
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: 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! |
|
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) |
|
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. |
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. |
|
npm being associated with open source feels like a natural mindset for people who were writing code before npm existed. I just looked this up they were bought by Github, not MS. I think it's a bit of a stretch to say MS runs and maintains npm. MS might not even be aware npm is in there for all we know. It could be 3 people who hope no one notices that they keep receiving paychecks, it could be those 3 people are on a beach right now and npm is just an auto-reply mailbox |
|
push |
|
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. |
|
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! |
|
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. |
|
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? |
|
Is there a Terraform provider or any IAC for setting all of this up? Removing some of the friction of setting up a bunch of accounts might help. I mean I totally get your point though. It's pretty risky to have a single username and password for npm. Single point of failure. Could get phished. But 6 usernames and passwords? 6x more secure. That's just math, innit |
|
I love how this "answer" was selected by someone besides the original poster and has nothing to do with the original post. Case closed, guys. The Bay Area npm product manager picked an answer said it was resolved. This thread will be a future golden example of how allowing these corpo goons into open source ruined everything. |
|
Thanks for the update @cha0s, I have unmarked that answer. This issue is still open with no resolution. |
|
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. |
|
Don't be rude. These are people doing their job to help others. I would be surprised if the people who make unpopular or out of touch decisions are dealing with the fallout, since anyone who can approve an acquisition can certainly stick some punching bags in front of those decisions rather than deal with it themselves. The people responding here are not out personally targeting your community for destruction, and the sunsetting of TOTP is not a weapon of oppression. This is hyperbolic nonsense that I think should be removed as it's off topic, insulting, unprofessional, and lowers the quality of discourse. There are appropriate ways to voice your opinion, or complain, or even be snarky, but this isn't one of them. Individually calling people out by name to insult them might fly in the toxic sludge fest that is the larger internet, but we should attempt to have a higher standard here on github. Like, let's limit criticism to things that are related to software and ideally the topic at hand, and keep insults vague and implied rather than tagging specific people. I typically avoid using categoricals under almost any circumstance, but I feel pretty confident in saying that sunsetting TOTP has never actually extinguished a community. |
|
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! This highlights the exact kind of devastating ecosystem compromises that forced npm to make these drastic, strict security changes in the first place. |
|
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
|
Due to the recent package manager worm Shai-Hulud, I strongly recommend revisiting the option to remove the authenticator-based 2FA method. Preventing users from using an effective protection measure against this threat, even if you do not consider it the best available method, is a net negative. Please reconsider and weigh the benefits against the drawbacks here. |
|
I'm so glad these brilliant ideas have prevented NPM supply chain attacks. Let's just close the discussion as "dormant". Great work, new community members! |
|
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
This comment was marked as spam.
This comment was marked as spam.
|
The main reason npm is moving away from TOTP is to improve account security against phishing attacks. While TOTP is still much better than having no 2FA, attackers can trick users into entering one-time codes on fake websites and use them immediately. WebAuthn and FIDO-based authentication are phishing-resistant because authentication is tied to the legitimate domain, and the private key never leaves the user's device. This significantly reduces the risk of account compromise, especially for maintainers of widely used packages. That said, many developers have raised valid concerns about accessibility, migration effort, and usability for small teams. Improving the transition experience while maintaining strong security is an important balance to achieve. |
This comment was marked as low quality.
This comment was marked as low quality.
|
Many of us use password managers which do not offer to fill passwords except on the website the credentials belong to (i.e. only when the page is cryptographically verified to be associated with site). Credentials not being offered is a huge red flag that immediately causes a stop and reevaluate. Are you claiming that password managers will be fooled by your AitM attack of concern? Perhaps you're claiming that an AitM could serve the valid page coming from npmjs.org and then cause that valid, unaltered page to redirect to their evil TOTP code collection page? Perhaps instead of altering the login page you are suggesting they can simply replace the valid TOTP page with their evil version after successful authentication has occurred and the TOTP page is being fetched? |
This comment was marked as spam.
This comment was marked as spam.
|
A far more effective and robust security measure than FIDO/WebAuthn was to do the right thing from start and make this ignore-scripts=true |
|
You mean, disallowing scripts to run when you do something you didn't expect to mean scripts would run? The thing we learned with Lotus 1-2-3 in 1989, and with Word in 1995? THAT thing? Noooo.... Surely you don't mean that... |
|
@lassevk In practice, only a small number of packages like |
|
hello @prahladyeri I think the change comes down to security rather than a dislike of TOTP itself. TOTP has worked well for years, but it's still vulnerable to phishing. If someone tricks you into entering your 6-digit code on a fake login page, they can use that code immediately to access your account. That's exactly the kind of attack npm maintainers have been targeted with. FIDO/WebAuthn is designed to prevent that. It verifies that you're signing in to the real website, so even if you land on a convincing phishing page, your security key or passkey won't authenticate it. That said, I understand why people are concerned. Not everyone wants to rely on hardware keys or newer authentication methods, and some worry about compatibility with their preferred operating system or browser. Fortunately, support for WebAuthn has improved a lot, including on Linux and Firefox, though there are still some rough edges. So while the transition may be inconvenient for some users, the motivation seems to be reducing the risk of compromised maintainer accounts and supply-chain attacks rather than making the ecosystem more closed. |
|
While I understand that TOTP is vulnerable to phishing, there really aren't any solutions that are completely invulnerable to any sort of attack. You might say "we've designed an idiot-proof authentication system!" but you know they're already hard at work on the next-gen idiot. Who hasn't learned at this point not to give people your TOTP code? And to like, I don't know, look at the address bar? I get it that a lot of people maybe haven't been using computers that long but are they the primary users of npm or something? I use a password manager and it won't even trigger if the site doesn't match. Someone might be able to get on my network, poison my DNS, secretly trust a CA, and get me to enter a TOTP code into a malicious site. But if they control my DNS and my CA trust store, and I don't notice, I'd bet they can get my passkey too. I mean, you can just straight up dump your passkeys to json. It's marginally better than a super long password for security, just far more annoying to use.
I migrated to passkeys right away when they became widely supported, and I migrated off of them about 6 months later. They're a distant annoyance in my rear view mirror. Not interested. Largely it comes down to a) way more annoying, b) marginally more secure at best. If your threat model is someone looking over your shoulder as you type it, ya passkeys are gonna stop that. If the threat model is grandma telling the nice man on the phone her password, grandma is safe. If the threat model is they've compromised your credential store, they're genuinely worse than TOTP. If someone gets my credential store, and I retain my phone number, that 2nd factor stops them. If someone gets my passkey out of my vault, that works as a single factor login on quite a few. So let's say we use the locked-to-a-device version to avoid that. Well, now you've gotta do this dance of logging in on every device you ever want to log in with to set up this hardware locked passkey. Hope you've got multiple devices in case you need to log in and one of the passkeys has been randomly deactivated. Hope it wasn't your last passkey. Maybe that's a built in security feature, maybe it's a bug, maybe it's a misunderstanding on my part. All I know is that I don't like it when my credentials stop working unexpectedly and I have to find an alternative device. And let's say I drop my phone in a river and it's got my passkey on there. The only copy, shucks. Now how do I get into this account? There are two options and they both suck. The first option is I don't. Account is gone. Second option is...now my account has NO 2fa? Awesome, I'm sure no one can exploit that
Thank you, I appreciate it. The empathy is palpable. I agree here, the transition off passkeys was inconvenient (google was the worst). I persevered and it felt good to be rid of them. I still use them where they are truly seamless. Apple, Paypal, very few others. But anywhere I have a passkey, I ALSO have a TOTP code. Because at the end of the day a passkey is just a really long annoying password you're not allowed to type in. And if you have a passkey and no TOTP, or you have a passkey and a password in the password manager together, well, I think that's just 1FA with more steps, right? |
|
i think the discussion is less about whether totp is secure or insecure, and more about balancing security with adoption. totp has weaknesses, but it is still a practical 2fa method that many developers already use. removing it completely may cause some users to disable 2fa instead of moving to a new method. a possible middle ground could be keeping totp as an option while strongly encouraging webauthn/passkeys for higher-risk accounts, similar to how many platforms handle security upgrades. improving the migration experience and recovery options is also important, because the best security method is the one users can actually use consistently. |
|
Having less people using 2FA just because some high-castle devs decided to limit the available methods for enabling it, is just making npm more insecure. In other words like asking for a feature request: Can we have accepted and user friendly 2FA methods like OTP? |
|
Hey, @prahladyeri! 👋 |
and others
Uh oh!
There was an error while loading. Please reload this page.
Select Topic Area
Question
Body
I've been aghast to know that
npmis 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?
All reactions