GitHub recently released some changes to the NPM ecosystem in relation to the security problems that have been arising and one of the most recent was that some attackers managed to take control of the coa NPM package and released updates 2.0.3, 2.0.4, 2.1.1, 2.1.3 and 3.1.3, which included malicious changes.
In relation to this and with the increasing incidence of repositories seizures of big projects and promoting malicious code Through compromise of developer accounts, GitHub is introducing extended account verification.
Separately, for maintainers and administrators of the 500 most popular NPM packages, mandatory two-factor authentication will be introduced early next year.
From December 7, 2021 to January 4, 2022, all maintainers who have the right to release NPM packages, but who do not use two-factor authentication, will be transferred to use extended account verification. Extended verification involves the need to enter a unique code that is sent via email when attempting to enter the npmjs.com site or perform an authenticated operation in the npm utility.
Extended verification does not replace but only supplements optional two-factor authentication previously available, which requires verification of one-time passwords (TOTP). Extended email verification does not apply when two-factor authentication is enabled. Starting February 1, 2022, the process of moving to mandatory two-factor authentication of the 100 most popular NPM packages with the most dependencies will begin.
Today we are introducing the improved login verification in the npm registry, and we will begin a staggered rollout for maintainers starting on December 7th and concluding on January 4th. Npm registry maintainers who have access to publish packages and do not have two-factor authentication (2FA) enabled will receive an email with a one-time password (OTP) when they authenticate through the npmjs.com website or the Npm CLI.
This emailed OTP will need to be provided in addition to the user's password before authenticating. This additional layer of authentication helps prevent common account hijacking attacks, such as credential stuffing, that use a user's compromised and reused password. It's worth noting that Enhanced Login Verification is meant to be an additional basic protection for all publishers. It is not a replacement for 2FA, NIST 800-63B. We encourage maintainers to opt for 2FA authentication. By doing this, you will not need to perform an enhanced login verification.
After completing the migration of the first hundred, the change will be propagated to the 500 most popular NPM packages in terms of number of dependencies.
In addition to the currently available application-based two-factor authentication schemes for generating one-time passwords (Authy, Google Authenticator, FreeOTP, etc.), in April 2022, they plan to add the ability to use hardware keys and biometric scanners for which there is support for the WebAuthn protocol, as well as the ability to register and manage various additional authentication factors.
Recall that according to a study conducted in 2020, only 9.27% of package managers use two-factor authentication to protect access, and in 13.37% of cases, when registering new accounts, developers tried to reuse compromised passwords that appear in known passwords.
During password strength analysis used, 12% of the accounts in NPM were accessed (13% of packages) due to the use of predictable and trivial passwords such as "123456". Among the problems were 4 user accounts of the 20 most popular packages, 13 accounts whose packages were downloaded more than 50 million times per month, 40 - more than 10 million downloads per month and 282 with more than 1 million downloads a month. Considering the load of modules along the chain of dependencies, compromising untrusted accounts could affect up to 52% of all modules in NPM in total.
Finally If you are interested in knowing more about it, you can check the details in the original note In the following link.