GitHub укараняе ў NPM абавязковую пашыраную верыфікацыю ўліковых запісаў

У сувязі з якія пачасціліся выпадкамі захопу рэпазітароў буйных праектаў і пасоўванні шкоднаснага кода праз кампраметацыю ўліковых запісаў распрацоўнікаў, кампанія GitHub уводзіць паўсюдную пашыраную верыфікацыю ўліковых запісаў. Асобна для суправаджаючых і адміністратараў 500 самых папулярных NPM-пакетаў у пачатку наступнага года будзе ўкаранёна абавязковая двухфактарная аўтэнтыфікацыя.

З 7 снежня 2021 года па 4 студзеня 2022 года будзе зроблены пераклад усіх мэйнтэйнераў, якія маюць права публікацыі NPM-пакетаў, але не выкарыстоўваюць двухфактарную аўтэнтыфікацыю, на выкарыстанне пашыранай верыфікацыі ўліковых запісаў. Пашыраная верыфікацыя мае на ўвазе неабходнасць уводу аднаразовага кода, які адпраўляецца на email пры спробе ўваходу на сайт npmjs.com або выкананні аўтэнтыфікаванай аперацыі ва ўтыліце npm.

Пашыраная верыфікацыя не замяняе, а толькі дапаўняе раней даступную апцыянальную двухфактарную аўтэнтыфікацыю, пры якой патрабуецца пацверджанне пры дапамозе аднаразовых пароляў (TOTP). Пры ўключэнні двухфактарнай аўтэнтыфікацыі пашыраная верыфікацыя па email не прымяняецца. Пачынаючы з 1 лютага 2022 года пачнецца працэс пераводу на абавязковую двухфактарную аўтэнтыфікацыю суправаджаючых 100 самых папулярных NPM-пакетаў, якія маюць найбольшую колькасць залежнасцяў. Пасля завяршэння міграцыі першай сотні, змена будзе распаўсюджана на 500 самых папулярных па колькасці залежнасцяў NPM-пакетаў.

Апроч даступнай у наш час схемы двухфактарнай аўтэнтыфікацыі на аснове прыкладанняў для генерацыі аднаразовых пароляў (Authy, Google Authenticator, FreeOTP і т.п.) у красавіку 2022 гады плануюць дадаць магчымасць выкарыстання апаратных ключоў і біяметрычных сканараў, для якіх маецца падтрымка пратаколу WebAuthn, а таксама магчымасць рэгістрацыі і кіравання рознымі дадатковымі фактарамі аўтэнтыфікацыі.

Нагадаем, што ў адпаведнасці з праведзеным у 2020 годзе даследаваннем, толькі 9.27% ​​мэйнтэнераў пакетаў выкарыстоўваюць для абароны доступу двухфактарную аўтэнтыфікацыю, а ў 13.37% выпадкаў пры рэгістрацыі новых уліковых запісаў распрацоўшчыкі спрабавалі паўторна выкарыстоўваць скампраметаваныя паролі, якія фігуруюць у вядомых уцечка. Падчас праверкі надзейнасці выкарыстоўваных пароляў атрымалася атрымаць доступ да 12% акаўнтаў у NPM (13% пакетаў) з-за выкарыстанні прадказальных і трывіяльных пароляў, такіх як "123456". У ліку праблемных апынуліся 4 уліковыя запісы карыстальнікаў з Top20 самых папулярных пакетаў, 13 уліковых запісаў, пакеты якіх загружалі больш за 50 млн раз у месяц, 40 – больш за 10 млн загрузак у месяц і 282 з больш за 1 млн загрузак у месяц. З улікам загрузкі модуляў па ланцужку залежнасцяў, кампраметацыя ненадзейных уліковых запісаў магла трапіць у суме да 52% ад усіх модуляў у NPM.

Крыніца: opennet.ru

Дадаць каментар