feedback on announced plan to kill TOTP

[ljharb]

Select Topic Area

Product Feedback

Body

Personally, I see this as a very harmful decision. It will kill my workflow; having to open a web browser is very disruptive (which is why i still use TOTP and not web auth), and my existing "publish from CI" setups that DO securely use two factors (as opposed to the automation/granular token-based workflows that use a single factor) rely on a TOTP.

Please do not remove this highly critical feature.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[leobalter]

meta response: as I mentioned in a slack thread from the OpenJS channel, I'll pick up to 3 feedback discussion posts pinned, all related to our recent publishing on our plan for a more secure npm supply chain.

[3nprob]

Thank you for raising this important topic, ljharb.

Agreed. Being able to do publishing fully from the terminal and without having to authenticate in a web browser is a workflow it'd be a pain to lose and arguably a reduction in security for some environments.

[sashahilton00]

Forcing people into passkeys is a bad idea.

The passkey authentication flow is clunky in it's current incarnation, in addition to this the current state of passkey management is unsatisfactory for many, in that it shepherds the user into a keystore that is in many ways a walled garden, especially in browser contexts.

Keys cannot easily be transferred across vendors in many cases, additionally the device sharing functionality that the major vendors (such as Apple & Google) have implemented, mean that in effect the passkey is only as secure as the vendor account password + some security questions.

The real benefits of webauthn, namely device-bound hardware keys, is not exposed/available in most cases. Whilst this remains the case, I would argue there isn't enough in favour of them to completely remove TOTP as an option, in addition to the other aforementioned reasons.

[KaKi87]

Keys cannot easily be transferred across vendors in many cases, additionally the device sharing functionality that the major vendors (such as Apple & Google) have implemented, mean that in effect the passkey is only as secure as the vendor account password + some security questions.

+1 for vendor lock-in. I store my TOTP tokens in a KDBX file (the open source vault format from KeePass) for the ability to use it on any device using any compatible app while preserving security, and therefore will never switch to passkeys for as long as these will require a backend, especially a GAFAM one.

I would say, time to move to JSR, but they exclusively offer login through GitHub^*, while GitHub owns NPM. 🤷 I also use TOTP on GitHub though, are they planning on removing that too ?

^* I just now submitted a feature request for JSR to support non-GitHub login.

[deviantintegral]

Much of the discussion about passkeys is from the individual perspective, but forcing people into passkeys is also bad for companies. Ours has changed password management apps a few times, and a key aspect was being able to migrate the organization's individual and shared credentials. For example, it's now been a year since 1Password announce some sort of passkey portability, yet it's still not really available if we wanted to migrate to Bitwarden.

I hope this decision is deferred until proper passkey portability is available from the major authentication apps.

[jakebailey]

Passkeys also cannot generically be shared between multiple people, e.g. for a locked off publishing account. The only place I've seen this work is Bitwarden between devices (which might work for a Bitwarden org), or I think Apple lets you do it if you use them as a password manager.

But if you want to have an on call rotation of people who may need to manually use an account (and do not want to add personal accounts to packages/orgs), TOTP is the only way to have any 2FA at all. I'm not aware of anyone dropping TOTP to this extent.

[Shur0v]

TOTP should remain supported for CI/CD workflows that rely on token-based authentication.
Web-based auth isn’t practical for automated systems and breaks secure publishing pipelines.
Keeping TOTP ensures flexibility while maintaining strong two-factor security.

[aiboost]

I vote for keeping TOTP alongside adding new authentication methods.

TOTP is extremely handy for semi-automatic package publishing when you copy your one-time password into the terminal from KeePass2, which stores literally all my passwords and TOTP secrets.

At the same time, I think adding PassKeys is a timely decision. When the number of services using PassKeys becomes high enough and the tools and technology itself mature, I’ll consider migrating. But currently, I don’t think PassKeys could make my UX with NPM either easier or more secure.

Please don’t force migration from TOTP. It’s better to nudge people to enable 2FA at least. There’s nothing worse for the popularization of 2FA than tools that change too quickly, breaking support for previous technologies in favor of the newest ones.

[hoesknowhoes]

TOTP: zero money
physical token: not zero money

[ve3]

I'm not familiar with security key. From npm document page ( https://docs.npmjs.com/configuring-two-factor-authentication ) said:

To configure a security-key requires a modern browser that support WebAuthn. This will allow you to configure a biometric devices featuring Apple Touch ID, Face ID, or Windows Hello as well as physical keys such as Yubikey, Thetis, or Feitian.

However, I don't have any physical key, no web cam, no fingerprint scanner. So, my Windows Hello has no available to any of these.

Then what option is left for someone like this?

[kylekorth]

Even the most secure systems on the planet support multiple forms of 2FA when implementing passkeys. This decision is myopic given the use case of automatic publishing and offers no viable alternatives.

[grzegorzjudas]

Would you care to explain the rationale of not providing the option for the user to select which one they want? Why force users to passkeys that might be hell to manage as of now, especially people (like me) that are used to the current workflow?

I'd understand recommending it explicitly, but leaving no option for alternative suggest you're in possession of research documents proving how passkeys are higly more secure than TOTP? If so, by all means, please do share. Otherwise everyone will just assume you're forcing people to use the method of your choice and showing the middle finger to everyone that disagrees.

[ve3]

I feel like I'm being given the middle finger right now.

[CookieHCl]

I really don't understand this "security decision".

1. Is TOTP NOT secure???? I understand that access tokens without expire date is unsecure, but isn't TOTP strong enough?
2. Does passkey provides more security than TOTP?

[phryneas]

It does, in the sense that a passkey only works on one domain and you can enter your TOTP on any phishing site. Sure, they can only use it for a short amount of time, but still.

[ckcr4lyf]

This is a horrible decision. Forcing users into passkeys, which are IMO to some degree "security by obscurity". Oh, you set it up on your Apple Keychain when using a mac? too bad, now you can't 2FA via your Linux laptop. None of these major players like Microsoft (Windows Hello) etc. will let you move your passkeys to a competitor, because they want to keep you as their customer.

Passkeys are IMO extremely anti-consumer, all in the name of "secure!! can't export so hackers can't get it!!!". Ok that is true and I get why companies enforce Yubikeys (and then provide their employees with one).

But for my personal services, I would always rather prefer RFC6238 compliant TOTP which let's the user retain control.

Another dumb decision.

[ckcr4lyf]

Some more reading on passkeys and their evil design: https://unixdigest.com/articles/are-passkeys-really-the-beginning-of-the-end-of-passwords-i-certainly-hope-not.html

[prahladyeri]

Agree with this assessment. For authentication between point A and B, why should a third party (such as FIDO Alliance partner) be involved at all? That alone feels like an anti-pattern or walled garden approach.

[jacobhumston]

I'm not super knowledgeable on how this kind of stuff works behind the scenes; but I don't really understand how TOTP is any less secure then passkeys. If someone gets in my google account for example, then my passkey is useless? In all the years I've used TOTP I have yet to run into any issues.

[sashahilton00]

The short version is as follows:

• Passkeys are basically cryptographic key pairs, so in that sense are more secure than passwords/TOTP. Practically speaking the additional security is debatable.
• Because an individual can't remember a cryptographic key, passkeys require vendor software to store and use the keys.
• Vendor software is as vendor software does; portability is bad, lock in is prevalent, control moves in the direction of the vendor.
• Passkeys also have 'attestation'. This is where the hardware that generates the keys has a trusted certificate from the manufacturer installed, which can be used to attest that the private key has been generated on a given piece of hardware and that the key cannot be extracted/used elsewhere/etc. This means that sites can in theory eg. only accept keys generated on Apple devices, or unrooted Android phones. It's a big step back in user control, and potentially disastrous for reverse engineering/vulnerability research/etc, and encourages security through obscurity and other bad practices. Think DRM for passwords.

A full discussion of the pros and cons would take far longer, and my objection hasn't been to them as an authentication mechanism per se, but rather as an authentication mechanism to the exclusion and detriment of all alternative mechanisms. Hypothetically, how would you feel if a vendor could revoke your access to a third party service where they otherwise had no involvement? If that kind of thing concerns you, then it would be worth reading up on passkeys before jumping into using them.

[KaKi87]

Think DRM for passwords.

This basically says everything, thank you.

[jsumners]

Please reconsider your decision to remove TOTP. If you move forward with it, I will be deprecating all of my personally published packages. Admittedly, most of them are trash, but there are a significant few that will cause ecosystem impact:

package	downloads between 2025-07-01 & 2025-09-30
abstract-logging	36,565,028
abstract-cache	167,456
self-cert	37,760
fastify-no-icon	36,107
@jsumners/line-reporter	13,736
abstract-cache-redis	12,603

You can review the full list if you like.

I will not deal with the WebAuthn methods that you support. I banked with an institution for almost 20 years and have recently moved all of my funds away from them because they started requiring that I get out my phone, open their app, and navigate through some menus to get to a 2FA code in order to login to their website or even talk to customer support. While their mechanism is still TOTP, the barrier I am unwilling to deal with is having to use a separate device to get the code. WebAuthn enforces this as baseline. If I can't utilize 1Password to fill in the OTP (yes, I know and I DO NOT CARE), then I am not going to deal with it.

Further, removing TOTP, and thus removing my access to npmjs.com in totality, will result in me not being able to manage the packages for Pino or the package for Fastify. To be clear: this is significantly impactful. There are not many people who have administrative rights to those packages. You're driving a bus straight in to one of them.

[vindicatorr]

Okay, first off, I upvoted a few comments here, and subscribed to this thread because I share(/ed) the same concern...

The main issue for me is what I view as an unnecessary cost with getting extra hardware (a $25+ yubikey (what of poor folks?)).

But looking a little more, since I saw keepassxc (cross-platform/open-source) had some "passkey" "something", I thought I'd finally explore that.
I just tested it, and it DOES work. You have to go through steps to set it up, which also includes using their browser extension (I originally didn't want to (still don't) because I wanted that separation), but it's doable for everyone.
I'll probably create a separate browser data location (eg chrome's --user-data-dir=<...>) solely for sites that use passkeys.
How it would translate for CLI stuff that you all may have issue with, I don't know. I know keepass has a cli.

What I won't ever accept is any place (even if it doesn't apply here) that no longer accepts the "Something you know" FA. The passkey should never be a replacement for that. (I suppose you could technically say that that factor would still be used in unlocking the database).

With all that said, I think I still I'd prefer TOTP for this one reason... I intend on air-gapping my security stuff on a device with no network capability. I currently have the database and other relevant stuff stored on external storage that is encrypted and temporarily accessed to copy the stuff to volatile storage and given appropriate permissions.
The intent/desire is at some point I would create a qrcode for the requested credentials on the airgapped device, then scan it for the device that needs it, where it pastes each field where needed.
Should a camera fail, I could always just manually type it in, and a TOTP is much shorter, and time-sensitive (which is good).

As an aside, coming here all stemmed from me having issues building a project and finding I was getting a 401 for esbuild during npm install.
I don't know if this is new as I built the project fine over a year ago and I've never had an npm account. The 401 may just be unrelated to the build (doubtful).

EDIT0: Might be good: https://keepassxc.org/docs/KeePassXC_UserGuide#_browser_passkey_support

[prahladyeri]

It's not just about spending $25 for a yubikey, it's also about vendor-lockin and having a walled garden or anti-commons approach. For authentication between point A and B, why should a third party (such as FIDO alliance partner) be involved at all? This alone looks like an anti-pattern.

[3nprob]

Update: GitHub have announced a revised timeline "based on your feedback" but are still moving forward with killing TOTP:

https://github.com/orgs/community/discussions/178140

What Hasn't Changed

The security improvements from October 13 remain in effect:

• New granular tokens: 7-day default, 90-day maximum lifetime
• TOTP 2FA: Cannot add new or reconfigure existing setups (existing TOTP still works)

My feedback on the update: https://github.com/orgs/community/discussions/178140#discussioncomment-14799045

---

New TOTP setups were disabled on October 13 and announced here: https://github.com/orgs/community/discussions/176828

[prahladyeri]

Very much agree with your post - TOTP shouldn't have been removed, there is nothing wrong with it.

If some genius package maintainer (allegedly) fell for a phishing scam, that doesn't indicate an issue with TOTP algorithm but problematic security practices on part of said maintainer.

Almost every kind of credential on this planet is subject to phishing including passwords, security keys, API tokens, OTPs, etc. That doesn't automatically make their associated authentication mechanisms insecure.

It's not just about spending USD 25 or so for a yubikey, it's also about vendor-lockin and having a walled garden or anti-commons approach. For authentication between point A and B, why should a third party (such as FIDO alliance member) be involved at all? This alone looks like an anti-pattern.