"Let's start with the original problem Historically, npm relied on classic tokens: long-lived, broadly scoped credentials that could persist indefinitely. If stolen, attackers could directly publish malicious versions to the author's packages (no publicly verifiable source code needed). This made npm a prime vector for supply-chain attacks. Over time, numerous real-world incidents demonstrated this point. Shai-Hulud, Sha1-Hulud, and chalk/debug are examples of recent, notable attacks."
"npm revoked all classic tokens and defaulted to session-based tokens instead. The npm team also improved token management. Interactive workflows now use short-lived session tokens (typically two hours) obtained via npm login, which defaults to MFA for publishing. The npm team also encourages OIDC Trusted Publishing, in which CI systems obtain short-lived, per-run credentials rather than storing secrets at rest."
npm revoked long-lived classic tokens and moved to short-lived session tokens, defaulting to MFA for publishing and improving token management. Interactive workflows now use session tokens typically valid for two hours obtained via npm login. The npm team encourages OIDC Trusted Publishing so CI systems obtain per-run credentials instead of storing secrets at rest. These measures cause credentials to expire quickly and require a second factor during sensitive operations. However, successful MFA-focused phishing campaigns that harvest one-time passwords and logins can still obtain short-lived tokens and allow malicious package publication, so projects remain vulnerable to supply-chain malware.
Read at The Hacker News
Unable to calculate read time
Collection
[
|
...
]