GitHub наскоро пусна някои промени в екосистемата на NPM във връзка с възникналите проблеми със сигурността и един от най-новите беше, че някои нападатели успяха да поемат контрола върху пакета coa NPM и пуснаха актуализации 2.0.3, 2.0.4, 2.1.1, 2.1.3 и 3.1.3. XNUMX, който включва злонамерени промени.
Във връзка с това и с нарастващата честота на конфискации в хранилища на големи проекти и популяризиране на злонамерен код Чрез компрометиране на акаунти на разработчици, GitHub въвежда разширена проверка на акаунта.
Отделно, за поддържащите и администраторите на 500-те най-популярни NPM пакета, в началото на следващата година ще бъде въведено задължително двуфакторно удостоверяване.
От 7 декември 2021 г. до 4 януари 2022 г. всички поддържащи, които имат право да пускат NPM пакети, но които не използват двуфакторно удостоверяване, ще бъдат прехвърлени да използват разширена проверка на акаунта. Разширената проверка включва необходимостта от въвеждане на уникален код, който се изпраща по имейл при опит за влизане в сайта npmjs.com или извършване на удостоверена операция в помощната програма npm.
Разширената проверка не замества, а само допълва незадължителната двуфакторна автентификация налични преди, което изисква проверка на еднократни пароли (TOTP). Разширената потвърждение на имейл не се прилага когато е активирана двуфакторна автентификация. От 1 февруари 2022 г. ще започне процесът на преминаване към задължително двуфакторно удостоверяване на 100-те най-популярни NPM пакета с най-много зависимости.
Днес въвеждаме подобрената проверка за влизане в регистъра на npm и ще започнем поетапно внедряване за поддържащите, започващо на 7 декември и приключващо на 4 януари. Поддръжниците на регистъра на Npm, които имат достъп до публикуване на пакети и нямат активирана двуфакторна автентификация (2FA), ще получат имейл с еднократна парола (OTP), когато се удостоверят чрез уебсайта npmjs.com или Npm CLI.
Това изпратено по имейл OTP ще трябва да бъде предоставено в допълнение към паролата на потребителя преди удостоверяване. Този допълнителен слой на удостоверяване помага за предотвратяване на често срещани атаки за отвличане на акаунти, като например препълване на идентификационни данни, които използват компрометирана и повторно използвана парола на потребителя. Струва си да се отбележи, че подобрената проверка на влизане е предназначена да бъде допълнителна основна защита за всички издатели. Не е заместител на 2FA, NIST 800-63B. Насърчаваме поддържащите да изберат 2FA удостоверяване. По този начин няма да е необходимо да извършвате подобрена проверка за влизане.
След завършване на миграцията на първите сто, промяната ще бъде разпространена в 500-те най-популярни NPM пакета по отношение на броя на зависимостите.
В допълнение към наличните в момента базирани на приложения двуфакторни схеми за удостоверяване за генериране на еднократни пароли (Authy, Google Authenticator, FreeOTP и др.), през април 2022 г. те планират да добавят възможност за използване на хардуерни ключове и биометрични скенери за които има поддръжка за протокола WebAuthn, както и възможност за регистриране и управление на различни допълнителни фактори за удостоверяване.
Припомнете си, че според проучване, проведено през 2020 г., само 9.27% от мениджърите на пакети използват двуфакторно удостоверяване за защита на достъпа, а в 13.37% от случаите, когато регистрират нови акаунти, разработчиците се опитаха да използват повторно компрометирани пароли, които се появяват в известни пароли .
По време на анализ на силата на паролата използван, 12% от сметките в NPM са били достъпни (13% от пакетите) поради използването на предвидими и тривиални пароли като "123456". Сред проблемите бяха 4 потребителски акаунта от 20-те най-популярни пакета, 13 акаунта, чиито пакети са били изтегляни повече от 50 милиона пъти месечно, 40 – повече от 10 милиона изтегляния на месец и 282 с повече от 1 милион изтегляния на месец. Като се има предвид натоварването от модули по веригата от зависимости, компрометирането на ненадеждни акаунти може да засегне до 52% от всички модули в NPM общо.
Накрая Ако се интересувате да научите повече за това, можете да проверите подробностите в оригиналната бележка В следващия линк.