GitHub ga nylig ut noen endringer i NPM-økosystemet i forhold til sikkerhetsproblemene som har oppstått og en av de siste var at noen angripere klarte å ta kontroll over coa NPM-pakken og ga ut oppdateringene 2.0.3, 2.0.4, 2.1.1, 2.1.3 og 3.1.3. XNUMX, som inkluderte ondsinnede endringer.
I forhold til dette og med økende forekomst av depotbeslag av store prosjekter og fremme ondsinnet kode Gjennom kompromittering av utviklerkontoer, introduserer GitHub utvidet kontoverifisering.
Separat, for vedlikeholdere og administratorer av de 500 mest populære NPM-pakkene, vil obligatorisk tofaktorautentisering bli introdusert tidlig neste år.
Fra 7. desember 2021 til 4. januar 2022, alle vedlikeholdere som har rett til å frigi NPM-pakker, men som ikke bruker tofaktorautentisering, vil bli overført til å bruke utvidet kontoverifisering. Utvidet verifisering innebærer behovet for å angi en unik kode som sendes via e-post når du prøver å gå inn på npmjs.com-siden eller utføre en autentisert operasjon i npm-verktøyet.
Utvidet verifisering erstatter ikke, men supplerer bare valgfri tofaktorautentisering tidligere tilgjengelig, noe som krever verifisering av engangspassord (TOTP). Utvidet e-postbekreftelse gjelder ikke når tofaktorautentisering er aktivert. Fra 1. februar 2022 starter prosessen med å gå over til obligatorisk tofaktorautentisering av de 100 mest populære NPM-pakkene med flest avhengigheter.
I dag introduserer vi den forbedrede påloggingsverifiseringen i npm-registeret, og vi starter en forskjøvet utrulling for vedlikeholdere som starter 7. desember og avsluttes 4. januar. Npm-registervedlikeholdere som har tilgang til å publisere pakker og ikke har tofaktorautentisering (2FA) aktivert, vil motta en e-post med et engangspassord (OTP) når de autentiserer seg gjennom nettstedet npmjs.com eller Npm CLI.
Denne engangskoden som sendes via e-post må oppgis i tillegg til brukerens passord før autentisering. Dette ekstra autentiseringslaget bidrar til å forhindre vanlige kontokapringsangrep, for eksempel påloggingsfylling, som bruker en brukers kompromitterte og gjenbrukte passord. Det er verdt å merke seg at Enhanced Login Verification er ment å være en ekstra grunnleggende beskyttelse for alle utgivere. Det er ikke en erstatning for 2FA, NIST 800-63B. Vi oppfordrer vedlikeholdere til å velge 2FA-autentisering. Ved å gjøre dette trenger du ikke å utføre en forbedret påloggingsverifisering.
Etter å ha fullført migreringen av de første hundre, vil endringen overføres til de 500 mest populære NPM-pakkene når det gjelder antall avhengigheter.
I tillegg til de for øyeblikket tilgjengelige applikasjonsbaserte tofaktorautentiseringsskjemaene for generering av engangspassord (Authy, Google Authenticator, FreeOTP, etc.), i april 2022 planlegger de å legge til muligheten til å bruke maskinvarenøkler og biometriske skannere som det er støtte for WebAuthn-protokollen for, samt muligheten til å registrere og administrere ulike ekstra autentiseringsfaktorer.
Husk at ifølge en studie utført i 2020, bruker bare 9.27 % av pakkebehandlerne tofaktorautentisering for å beskytte tilgangen, og i 13.37 % av tilfellene, ved registrering av nye kontoer, prøvde utviklere å gjenbruke kompromitterte passord som vises i kjente passord .
Under analyse av passordstyrke brukt, 12 % av kontoene i NPM ble åpnet (13 % av pakkene) på grunn av bruk av forutsigbare og trivielle passord som "123456". Blant problemene var 4 brukerkontoer av de 20 mest populære pakkene, 13 kontoer hvis pakker ble lastet ned mer enn 50 millioner ganger per måned, 40 – mer enn 10 millioner nedlastinger per måned og 282 med mer enn 1 million nedlastinger i måneden. Tatt i betraktning belastningen av moduler langs kjeden av avhengigheter, kan kompromittering av upålitelige kontoer påvirke opptil 52 % av alle moduler i NPM totalt.
Endelig Hvis du er interessert i å vite mer om det, du kan sjekke detaljene i det originale notatet I den følgende lenken.