image

GitHub verplicht 2FA voor beheerders honderd populairste npm-packages

donderdag 3 februari 2022, 17:05 door Redactie, 7 reacties

GitHub gaat alle beheerders van belangrijke en populaire npm-packages verplichten om in te loggen door middel van tweefactorauthenticatie (2FA) en voor de honderd populairste npm-packages is dit inmiddels het geval. Met de maatregel wil GitHub, dat eigenaar van npm is, de veiligheid van de npm registry vergroten.

Npm is de standaard package manager voor de JavaScript-omgeving Node.js en naar eigen zeggen het grootste softwarearchief ter wereld. Via het npm registry biedt het een groot archief met openbare, besloten en commerciële packages. De afgelopen jaren verschenen geregeld malafide npm-packages in de registry. In 2020 bleek dat meer dan negentig procent van npm-ontwikkelaars geen 2FA gebruikte om het eigen account te beveiligen.

Om alle "high-impact" npm-packages te beschermen moeten de maintainers en uitgevers van deze packages via 2FA gaan inloggen. Voor de Top 100-packages is dat inmiddels gedaan. Van maintainers die op dit moment geen 2FA gebruiken is de websessie ingetrokken. Ze zullen eerst 2FA moeten instellen voordat ze bepaalde acties met hun account kunnen uitvoeren, zoals het wijzigen van e-mailadressen en toevoegen van nieuwe maintainers. Voor alle andere high-impact packages zal de 2FA-verplichting vanaf 1 maart gaan gelden.

Reacties (7)
03-02-2022, 18:02 door Anoniem
Als je devs buiten hun GitHub account sluit door 2FA af te dwingen, dan zullen ze zeker geen bugs pletten.
Als een APT code in GitHub wil veranderen voor haar spionage doeleinden, dan zal het moeten aanmaken van een 2FA account ze niet tegenhouden.

Twee keer faal dus van GitHub. Dit gaat niets oplossen. Ik neem aan dat de meest devs op GitHub hier niet voor betaald krijgen. Een deel (90%?) zal zeggen: zoek het maar uit.
03-02-2022, 20:54 door Anoniem
Door Anoniem: Als je devs buiten hun GitHub account sluit door 2FA af te dwingen, dan zullen ze zeker geen bugs pletten.
Als een APT code in GitHub wil veranderen voor haar spionage doeleinden, dan zal het moeten aanmaken van een 2FA account ze niet tegenhouden.

Github zegt dat je als maintainer van een veel gebruikte module een basisverantwoordelijkheid, laten we zeggen ,'sociale plicht' hebt om je account behoorlijk te beveiligen.

Het threat model wat 2FA moet voorkomen is niet dat "APT actor maakt account aan" , maar "APT actor gebruikt compromised account van een trusted dev" .

Iets wat over het algemeen makkelijker is wanneer er slechts een password gebruikt wordt - zeker omdat je moet vrezen dat het niet gebruiken van 2FA door de dev geen overwogen keuze is die gecompenseerd is door een ultra lang single use password, maar gevolg van een mindset "geen zin in gedoe gewoon een password dat ik ff intik" .


Twee keer faal dus van GitHub. Dit gaat niets oplossen. Ik neem aan dat de meest devs op GitHub hier niet voor betaald krijgen. Een deel (90%?) zal zeggen: zoek het maar uit.

Zie boven, die faal heb je niet zo erg aangetoond.

Ik snap niet zo goed waarom je vindt dat ontwikkelaars van veel gebruikte modules prima met een slecht beveiligd account
moeten kunnen werken .
03-02-2022, 22:18 door _Martin_
De afgelopen jaren verschenen geregeld malafide npm-packages in de registry.
Da's voor elke package-manager natuurlijk een risico. Houd maar eens zicht op welke packages (en dependencies!) er daadwerkelijk worden gedownload. Package-managers zijn een mooie uitvinding, maar er hoeft maar één rotte appel/package bij te zitten.
03-02-2022, 23:02 door Anoniem
Door Anoniem: Ik snap niet zo goed waarom je vindt dat ontwikkelaars van veel gebruikte modules prima met een slecht beveiligd account
moeten kunnen werken .

GitHub vergeet wie al het programmeerwerk doet. En 2FA is geen panacee. Zoals je zegt is een ultra lang uniek wachtwoord ook heel goed. Vooral als je die op de juiste site gebruikt en met een veilige machine waar vanaf je werkt.
03-02-2022, 23:37 door Anoniem
Door _Martin_:
De afgelopen jaren verschenen geregeld malafide npm-packages in de registry.
Da's voor elke package-manager natuurlijk een risico. Houd maar eens zicht op welke packages (en dependencies!) er daadwerkelijk worden gedownload. Package-managers zijn een mooie uitvinding, maar er hoeft maar één rotte appel/package bij te zitten.
Kan jij mij ook uitleggen wat 2FA helpt om dit probleem op te lossen?
04-02-2022, 09:05 door Anoniem
Door _Martin_:
De afgelopen jaren verschenen geregeld malafide npm-packages in de registry.
Da's voor elke package-manager natuurlijk een risico. Houd maar eens zicht op welke packages (en dependencies!) er daadwerkelijk worden gedownload. Package-managers zijn een mooie uitvinding, maar er hoeft maar één rotte appel/package bij te zitten.
Dat klopt en deze maatregel gaat natuurlijk niemand ervan weerhouden om een nieuw malafide NPM pakket toe te voegen. Maar het maakt de kans wel aanzienlijk kleiner dat een bekend en veelgebruikt pakket aangepast wordt doordat een aanvaller toegang heeft verkregen tot het account van een ontwikkelaar.
04-02-2022, 11:52 door Anoniem
Door Anoniem:
Door Anoniem: Ik snap niet zo goed waarom je vindt dat ontwikkelaars van veel gebruikte modules prima met een slecht beveiligd account
moeten kunnen werken .

GitHub vergeet wie al het programmeerwerk doet. En 2FA is geen panacee. Zoals je zegt is een ultra lang uniek wachtwoord ook heel goed. Vooral als je die op de juiste site gebruikt en met een veilige machine waar vanaf je werkt.

panacee's bestaan op geen enkel vlak. Het niet bestaan ervan is geen reden om een dingen die wel beter kunnen ook beter te doen.

Bot gezegd : jammer voor die paar devs die wel heel secure werken met alleen een password .

Degenen die er met de pet naar gooien met hun hallo123 password - verdienen niet het vertrouwen dat ze hebben als dev van een top-100 package.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.