GitHub ha recentemente rilasciato alcune modifiche all'ecosistema NPM in relazione ai problemi di sicurezza che sono sorti e uno dei più recenti è stato che alcuni aggressori sono riusciti a prendere il controllo del pacchetto coa NPM e hanno rilasciato gli aggiornamenti 2.0.3, 2.0.4, 2.1.1, 2.1.3 e 3.1.3. XNUMX, che includeva modifiche dannose.
In relazione a ciò e con la crescente incidenza dei sequestri di archivi di grandi progetti e promuovere codice dannoso Attraverso la compromissione degli account degli sviluppatori, GitHub sta introducendo la verifica estesa dell'account.
Separatamente, per i manutentori e gli amministratori dei 500 pacchetti NPM più popolari, l'autenticazione a due fattori obbligatoria sarà introdotta all'inizio del prossimo anno.
Dal 7 dicembre 2021 al 4 gennaio 2022, tutti i manutentori che hanno il diritto di rilasciare pacchetti NPM, ma che non utilizzano l'autenticazione a due fattori, verranno trasferiti per utilizzare la verifica estesa dell'account. La verifica estesa implica la necessità di inserire un codice univoco che viene inviato via e-mail quando si tenta di accedere al sito npmjs.com o di eseguire un'operazione autenticata nell'utility npm.
La verifica estesa non sostituisce ma integra solo l'autenticazione a due fattori opzionale precedentemente disponibile, che richiede la verifica delle password monouso (TOTP). La verifica e-mail estesa non si applica quando l'autenticazione a due fattori è abilitata. A partire dal 1° febbraio 2022, inizierà il processo di passaggio all'autenticazione a due fattori obbligatoria dei 100 pacchetti NPM più popolari con il maggior numero di dipendenze.
Oggi stiamo introducendo la verifica dell'accesso migliorata nel registro npm e inizieremo un'implementazione scaglionata per i manutentori a partire dal 7 dicembre e si concluderà il 4 gennaio. I manutentori del registro Npm che hanno accesso per pubblicare pacchetti e non hanno l'autenticazione a due fattori (2FA) abilitata riceveranno un'e-mail con una password monouso (OTP) quando si autenticano tramite il sito Web npmjs.com o la CLI di Npm.
Questa OTP inviata per e-mail dovrà essere fornita in aggiunta alla password dell'utente prima dell'autenticazione. Questo livello aggiuntivo di autenticazione aiuta a prevenire attacchi comuni di dirottamento dell'account, come il riempimento delle credenziali, che utilizzano la password compromessa e riutilizzata di un utente. Vale la pena notare che la verifica dell'accesso avanzata è pensata per essere un'ulteriore protezione di base per tutti i publisher. Non sostituisce 2FA, NIST 800-63B. Incoraggiamo i manutentori a optare per l'autenticazione 2FA. In questo modo, non sarà necessario eseguire una verifica avanzata dell'accesso.
Dopo aver completato la migrazione dei primi cento, la modifica verrà propagata ai 500 pacchetti NPM più popolari in termini di numero di dipendenze.
Oltre agli schemi di autenticazione a due fattori basati su applicazioni attualmente disponibili per la generazione di password monouso (Authy, Google Authenticator, FreeOTP, ecc.), nell'aprile 2022, prevedono di aggiungere la possibilità di utilizzare chiavi hardware e scanner biometrici per il quale esiste il supporto per il protocollo WebAuthn, oltre alla possibilità di registrare e gestire vari fattori di autenticazione aggiuntivi.
Ricordiamo che secondo uno studio condotto nel 2020, solo il 9.27% dei gestori di pacchetti utilizza l'autenticazione a due fattori per proteggere l'accesso e nel 13.37% dei casi, durante la registrazione di nuovi account, gli sviluppatori hanno cercato di riutilizzare le password compromesse che appaiono nelle password note .
Durante l'analisi della sicurezza della password Usato, È stato effettuato l'accesso al 12% degli account in NPM (13% dei pacchetti) a causa dell'uso di password prevedibili e banali come "123456". Tra i problemi c'erano 4 account utente dei 20 pacchetti più popolari, 13 account i cui pacchetti sono stati scaricati più di 50 milioni di volte al mese, 40 - più di 10 milioni di download al mese e 282 con più di 1 milione di download al mese. Considerando il carico di moduli lungo la catena delle dipendenze, la compromissione di account non attendibili potrebbe interessare fino al 52% di tutti i moduli in NPM in totale.
Infine Se sei interessato a saperne di più, puoi controllare i dettagli nella nota originale nel seguente link