Replies: 16 comments 11 replies
-
| 💬 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 ⏩ 
 Where to look to see what's shipping 👀 
 What you can do in the meantime 💻 
 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. ⭐ | 
Beta Was this translation helpful? Give feedback.
-
| 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. | 
Beta Was this translation helpful? Give feedback.
-
| 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. | 
Beta Was this translation helpful? Give feedback.
-
| TOTP should remain supported for CI/CD workflows that rely on token-based authentication. | 
Beta Was this translation helpful? Give feedback.
-
| 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. | 
Beta Was this translation helpful? Give feedback.
-
| TOTP: zero money | 
Beta Was this translation helpful? Give feedback.
-
| I'm not familiar with security key. From npm document page ( https://docs.npmjs.com/configuring-two-factor-authentication ) said: 
 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? | 
Beta Was this translation helpful? Give feedback.
-
| 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. | 
Beta Was this translation helpful? Give feedback.
-
| 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. | 
Beta Was this translation helpful? Give feedback.
-
| I really don't understand this "security decision". 
 | 
Beta Was this translation helpful? Give feedback.
-
| 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. | 
Beta Was this translation helpful? Give feedback.
-
| 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. | 
Beta Was this translation helpful? Give feedback.
-
| 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: 
 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  | 
Beta Was this translation helpful? Give feedback.
-
| 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  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. As an aside, coming here all stemmed from me having issues building a project and finding I was getting a 401 for  EDIT0: Might be good: https://keepassxc.org/docs/KeePassXC_UserGuide#_browser_passkey_support | 
Beta Was this translation helpful? Give feedback.
-
| 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 
 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 | 
Beta Was this translation helpful? Give feedback.
-
| 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. | 
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions