RE: https://infosec.exchange/@jviide/115180291441974796
To recap, NPM allows 2FA TOTP token reuse within the token’s validity window.
I reported this and was told it’s a “known low-risk issue” and that they “don’t consider this to present a significant security risk.”
So, let’s look at how this seemingly small issue could be leveraged by a phisher. 1/
In NPM, a package can be configured to require 2FA for publishing (“Require two-factor authentication and disallow tokens”).
However, if an attacker phishes your password and a valid TOTP code, they can reuse them to publish packages in your name.
But at least the time window is limited, right? 2/
The “require 2FA for publishing” setting can’t be downgraded without a 2FA check.
But the attacker can reuse the phished TOTP code to perform a downgrade and allow publishing with “a granular access token with bypass 2FA enabled.”
Granular access tokens can be created without any 2FA checks. 3/
So, with a single phished NPM TOTP token + password combo, a well-prepared (automated?) attacker can quickly list your packages, downgrade some of their publishing requirements, and then create a granular token.
This extends the attacker's window for publishing nasty versions of your packages. 4/
What should you do as a package maintainer?
I’d argue that “don’t get phished” isn’t very constructive advice. To err is human.
Upgrading to phishing-resistant 2FA methods such as passkeys is a good idea. See https://docs.npmjs.com/configuring-two-factor-authentication#enabling-2fa
But this would require all maintainers to act. 5/
In the end, it would be best if NPM just blocked TOTP reuse.
TOTP stands for “Time-based One-Time Password,” after all. The “one-time” property is important enough to account for 50% of the acronym. 🙂
Even the spec explicitly calls for blocking reuse: https://datatracker.ietf.org/doc/html/rfc6238#section-5.2 6/6
Joachim Viide
Ben Stokman