GitHub verplicht vanaf 2023 tweefactorauthenticatie voor alle actieve gebruikers

GitHub verplicht vanaf eind volgend jaar het gebruik van tweefactorauthenticatie voor ontwikkelaars die actief code bijdragen aan het platform. De verplichting wordt in de loop van het jaar gefaseerd ingevoerd.

GitHub wil de verplichting eind 2023 laten gelden voor iedere actieve ontwikkelaar op het platform. Tegen die tijd moeten gebruikers een of meer vormen van meertrapsauthenticatie inschakelen in hun account.

Het platform deelt gebruikers in groepen in. Vanaf maart vraagt het platform gefaseerd aan die groepen om 2fa in te stellen voor hun account. GitHub wil uitdrukkelijk niet uitleggen hoe gebruikers in die groepen worden ingedeeld of in welke groep een gebruiker terechtkomt, maar het bedrijf gebruikt daarvoor in ieder geval vijf criteria:

• gebruikers die GitHub- of OAuth-apps of packages hebben gepubliceerd;
• gebruikers die een release-repo hebben gemaakt;
• enterprise- en organization-admins;
• gebruikers die code hebben bijgedragen aan repo's die door npm, OpenSSD, PyPI of RubyGems als belangrijk worden aangemerkt;
• gebruikers die code hebben bijgedragen aan de ongeveer vier miljoen grootste publieke en private repo's.

GitHub gaat per cohort kijken naar hoe de uitrol van de 2fa-verplichting loopt en past het proces op basis daarvan aan. Dat begint in maart volgend jaar. Het proces moet eind 2023 afgerond zijn.

Gebruikers krijgen 45 dagen vooraf waarschuwingen over de verplichting via GitHub en via e-mail. Als gebruikers die negeren, krijgen ze vanaf de dag dat de verplichting voor hen actief wordt, iedere keer als ze op het platform komen een notificatie. Die kunnen ze een week ter zijde leggen, daarna wordt hun account ontoegankelijk totdat tweetrapsauthenticatie actief wordt gemaakt. Gebruikers kunnen een totp-code of sms inzetten om hun account te beveiligen. Ook kunnen ze een securitysleutel gebruiken, maar alleen in combinatie met een totp-code.

Reacties (48)

Ik snap dat dit voor een hoop projecten logisch is, maar ik zet af en toe wat knutsel dingen online. Is het dan zo belangrijk? Nee, en daarom wil ik ook de keuze hebben. Je wordt overal al richting 2fa gedwongen en voor hobby zaken heb ik daar altijd een probleem mee. Ik vindt dat het mijn keuze moet blijven en niet afgedwongen moet worden. Zakelijke mag dat natuurlijk wel, maar voor hobby dingen moet ik die keuze kunnen maken. Dan maar volledige over naar mijn eigen gitlab en niets meer delen met de wereld. Het is niet anders.....

Voor het self hosten als je niet heel veel ci/cd en scrum dingetjes doet zou ik Gitea gebruiken. Gitlab zelf hosten heeft een paar quirks.

En je kan ook Gitea instellen om een repo te pushen/mirroren naar Gitlab of Github als je dat wil.

[Reactie gewijzigd door Hydranet op 15 december 2022 15:19]

Als je dan toch al amper inlogt, wat maakt get uit dat je dan een code uit je app in moet vullen?

Normaliter ben ik tegen alle bemoeienis en betutteling, maar 2fa vindt ik dus gewoon okay.

Ik vindt het gewoon gedoe, ligt aan mij. Vooral omdat ik dan weer moet opstaan om mijn telefoon te zoeken om de SMS code over te type.

Ik gebruik gewoon een OTP app. En als ik het echt vervelend vindt, dan gooi je die key toch in python en laat je een 2fa code uitpoepen?

Inderdaad! Zelf gebruik ik Authy hun desktop (Windows, MacOS, Android, ...) applicatie. Geen gedoe meer om je telefoon steeds uit je zakken te moeten halen.

[Reactie gewijzigd door Ken G op 15 december 2022 15:39]

Ik vertrouw niet zomaar een closed source app met dit soort dingen, dat is toch echt wel erom vragen dat je 2FA keys een keer op straat liggen ofzo.

Ook een van de redenen dat ik een yubikey gebruik ipv smsjes

En dit ligt dan thuis terwijl ik op het werk even inlog op mijn prive account. Fysieke keys zijn nog veel irritanter.....

Hoezo? Je hangt deze toch gewoon aan je sleutelbos die je weer nodig hebt om je voordeur in te komen.

Werken die keys ook op een VM in de cloud welke je via Citrix benaderd?

Als je usb passtrough hebt wel natuurlijk (geen idee of Citrix dit een beetje goed kan, mijn werk heeft allemaal linux/mac/windows apparaten gemengd dus zou bij ons niet werken). Anders de yubico authenticator lokaal draaien en de codes kopiëren / plakken.

[Reactie gewijzigd door jwd42 op 16 december 2022 10:09]

Daarom zal jij waarschijnlijk ook deze keuze blijven houden, ook bij GitHub.

Het is alleen verplicht als je voldoet aan één van de punten uit dit artikel. Meeste hobby-projecten hebben dat niet.

Ik vind dit een hele nette lijst. Als jij code bijdraagt aan (grote) open-source projecten, of software released op GitHub, dan ben je ineens niet meer het enige potentiële slachtoffer. Jouw gehackte account kan dan misbruikt worden om malware te verspreiden naar andere mensen. Ben eerlijk gezegd zeer blij met deze stap.

Hopelijk wel. Die release repo regel is mij nog niet helemaal duidelijk. Waarschijnlijk gebruik ik het dan niet

Is inderdaad niet heel duidelijk. GitHub zelf legt het iets anders uit:

Users who created a release

Als de rechterkant van elk van jouw projecten er zo uit ziet, dan zou ik er vanuit gaan dat je voorlopig nog goed zit (zolang je account niet gehacked wordt )

Eeh, ik maak wel releases

Ik snap dat dit voor een hoop projecten logisch is, maar ik zet af en toe wat knutsel dingen online. Is het dan zo belangrijk? Nee, en daarom wil ik ook de keuze hebben.

Je hebt de keuze om je eigen git repository te hosten of om over te stappen naar een andere partij.

Dan maar volledige over naar mijn eigen gitlab en niets meer delen met de wereld. Het is niet anders.....

Het één sluit het ander niet uit. GitLab kan je ook online afnemen, als je niets zelf publiekelijk wilt hosten.

[Reactie gewijzigd door The Zep Man op 15 december 2022 13:30]

Andere kant, iedereen in de goede richting duwen en aanleren om de veiligere methodes te gebruiken ,lijkt me goed.
Ik gebruik GitHub met mijn hardware sleutel (FIDO2 en U2F).
Inloggen op de site is user+pw en dan hardware sleutel.
Om met Git in te checken, heb ik met OpenSSH een “ecdsa-sk”/“ed25519-sk" ssh-key gemaakt.
Dan is het wachtwoord invoeren voor de ssh-key en knopje drukken.

Ik denk dat nu het huidige probleem is dat diverse tools die allemaal nog niet ondersteunen.
Maar nu wel, ik denk in positieve zin, gedwongen worden om dit wel te doen.
Vergelijkbaar dat MS oauth verplicht met imap/pop.
Lastig als je client dat nog niet ondersteunt maar uiteindelijk wel een veiligere oplossing.

[Reactie gewijzigd door vDorst op 16 december 2022 13:20]

Ook voor jou eigen repository, zelfs alleen voor eigen gebruik is het handig/raadzaam om de beveiliging goed in te stellen.

Het grootste misbruik is immers dat iemand anders jou repository gebruikt om zijn/haar code te hosten en te verspreiden. Dat gebeurt dan allemaal uit jou naam en je wilt niet weten wat er met die code allemaal wel mogelijk is.

Je wordt overal al richting 2fa gedwongen en voor hobby zaken heb ik daar altijd een probleem mee.

Want? LastPass en Bitwarden hebben gewoon TOTP ingebouwd tegenwoordig, dan is het één extra toetsencombinatie om nog een keer je 2FA in te vullen.
Beter is om er een los apparaat voor te hebben, maar liever ingebouwd in je password manager dan helemaal niks..

1password voert hem op github zelfs standaard in. Gecombineerd met dat github automatisch doorgaat als je een code hebt ingevuld zorgt ervoor dat dat scherm komt en gaat.

En dan is het weer geen MFA meer

En dan, op een dag, krijgen aanvallers je account in handen. Een account dat al jaren bestaat, regelmatig wat posted erdus vertrouwd uit kan zien. Een ideaal account om temisbruiken.

Eenmalig voor elk nieuw apparaat een code ontvangen is prima, maar niet elke keer. 2fa elke keer is niet nodig en irritant.

Het is niet minder belangrijk door het maar hobby te noemen. Wat jij hobby noemt kan voor een ander belangrijk genoeg worden bevonden om er via github gebruik van te maken. Github heeft daarbij ook een verantwoordelijkheid om zelf duidelijke grenzen te stellen aan moeite in ruil voor wat ze je allemaal makkelijker maken.
Natuurlijk zou die grens ook kunnen zijm dat je verplicht om de zoveel tijd aan github moet bevestigen dat jij geen zin hebt in 2fa en de volle verantwoordelijkheid neemt voor de moeite die github er dan aan kan hebben. Maar ik vermoed dat die kleine moeite makkelijker en goedkoper is dan net doen alsof het niet zo belangrijk is zonder dat expliciet te erkennen.

Gebruikers kunnen een totp-code of sms inzetten om hun account te beveiligen. Ook kunnen ze een securitysleutel gebruiken, maar alleen in combinatie met een totp-code.

Gezien GitHub van Microsoft is, vreesde ik dat ze Microsoft Authenticator zouden verplichten.

TOTP is best. Werkt goed i.c.m. de juiste password managers.

Is de Microsoft Authenticator niet gewoon een implementatie van een open standaard, zoals de Google Authenticator dat ook is? Over het algemeen maakt het niks uit welke tool je gebruikt omdat ze allemaal hetzelfde werken.

Is de Microsoft Authenticator niet gewoon een implementatie van een open standaard, zoals de Google Authenticator dat ook is? Over het algemeen maakt het niks uit welke tool je gebruikt omdat ze allemaal hetzelfde werken.

Volgens mij ondersteunt Microsoft Authenticator TOTP voor niet-Microsoft diensten, maar wordt voor Microsoft (gehoste)-diensten een eigen implementatie gebruikt die mogelijk afgedwongen wordt, die niet in password managers ondersteund wordt.

Dit houdt dus in dat Microsoft Authenticator ook gebruikt kan worden voor GitHub MFA d.m.v. generieke TOTP-ondersteuning, maar het is niet verplicht.

[Reactie gewijzigd door The Zep Man op 15 december 2022 13:26]

Ik heb ooit een eigen client hiervoor gebouwd (specifiek voor Microsoft diensten), en dat was gewoon op basis van een standaard API. Volgens mij is het enige verschil dat je voor MS Authenticator de QR code kunt gebruiken, maar voor andere clients een code moet intypen.

[Reactie gewijzigd door Wolfos op 15 december 2022 14:56]

QR is standaard bij zowat elke TOTP app, maar de MS Authenticator ondersteunt voor MS services ook dat je effectief een notificatie krijgt en kan goedkeuren met bv. Face ID op Apple apparaten.

Nee hoor. Authy voldoet ook

Gezien GitHub van Microsoft is, vreesde ik dat ze Microsoft Authenticator zouden verplichten.

Waarom denk je dat, in Office 365 kun je ook gewoon TOTP gebruiken.

TOTP is best. Werkt goed i.c.m. de juiste password managers.

Niet vergeten dat dat niet veel veiliger is dan helemaal geen 2FA. Immers heb je nu beide factoren op 1 plek staan. Iemand die toegang heeft tot de password manager heeft dus ook toegang tot de 2FA codes. Waarmee het dus weer gewoon 1FA is. Voor zover OTP überhaupt niet valt in te scharen onder de factor "kennis", waar wachtwoord ook al onder valt. Immers valideert OTP helemaal niks behalve kennis van / toegang tot de code. Of je die code nu "lokaal" ontvangt of aan de andere kant van de wereld en via een ander medium doorstuurt ("eey Pietje, hoe kan ik inloggen op jouw GitHub account?" => $gebruikersNaam + $wachtwoord => inloggen => Pietje ontvangt de OTP code per SMS => $otpCode). Het valideert dus helemaal niet dat je in het bezit bent van een telefoon (met een app, of die de SMS ontvangt). Het valideert dat je de OTP code weet. I.t.t. tot een Yubikey die je fysiek moet aansluiten of "bij het apparaat houden" (NFC). En Chrome + Android kan volgens mij ook als 2FA gebruikt worden, maar AFAIK is Bluetooth dan een vereiste waarbij de PC / laptop en Android telefoon via bluetooth "zien" dat ze bij elkaar zijn. Het kan dan dus niet iemand anders / op ren andere locatie met jouw gebruikersnaam + wachtwoord inloggen en dat je zelf op telefoon de login bevestigd, omdat het apparaat waarmee je inlogt en het 2FA apparaat niet bij elkaar in de buurt zijn.

Yubikey die je fysiek moet aansluiten of "bij het apparaat houden" (NFC).

Ik vraag me af hoe moeilijk dat remote te doen is. Het USB protocol kan zover ik weet prima via een netwerk/internet verbinding lopen, en ongetwijfeld kun je NFC ook op de een of andere manier remote toegankelijk maken, hetzij door de radiogolven 'op te nemen' en elders af te spelen, of door via de API iets te knutselen. Uiteindelijk, in de telefoon/computer, is NFC een API. En tussen de API en het NFC device loopt een stroom bitjes. Dus als je de stroom bitjes kunt sturen, of je kunt de API implementeren, dan kun je overal NFC of USB doen.

Het lijkt me dat het enige wat je bij enige vorm van automatische 2FA (dwz: zonder dat een mens iets handmatig controleert) zeker kunt weten, is dat de andere partij toegang heeft tot de tweede factor. En bij wachtwoorden is het eigenlijk hetzelfde als ze in een wachtwoordmanager staan: de tegenpartij heeft toegang tot de inhoud van de wachtwoordmanager. Niets 'kennis' dus...

Ik ben het dus 200% met je eens, dat integratie van 2FA in je wachtwoordmanager geen toegevoegde veiligheid biedt, en eigenlijk juist het idee van 2FA de nek omdraait - zoals gebruikelijk in de wereld: authenticatie is onhandig, en tenzij mensen gedwongen worden, zullen ze zo veel mogelijk moeite doen om de authenticatie zo onveilig mogelijk te maken, zodat ze er zo min mogelijk last van hebben.

Het enige wat je nog kunt doen (misschien gebeurt dat al?), is de request/response tijd meten, en falen als de communicate met het NFC-device te lang duurt (of met het USB-device). En dan krijg je ongetwijfeld dat verbinding tussen PC en authenticatie-device om allerlei redenen slecht kan zijn, waardoor de authenticatie te vaak mislukt, en de authenticatie-devices als onbetrouwbaar worden gezien. Zodat ze alsnog niet gebruikt worden... En dat soort request-timing heeft überhaupt geen zin als de tegenpartij aan de andere kant van een internetverbinding zit, want de (veel grotere) vertraging en het gebrek aan consistentie van de internet-verbinding maakt het feitelijk onmogelijk om de request-tijd te meten richting het authenticatie-device. Het is dan onmogelijk vast te stellen of het device naast de computer van de tegenpartij ligt, of via een tweede verbinding zich aan de andere kant van de wereld bevindt...

Met remote USB / USB over IP oplossingen zul je mogelijk / waarschijnlijk alsnog een hardware key aan de andere kant kunnen gebruiken. Maar dan is er wel iets meer kennis nodig, om dit doelbewust te doen. En dus niet voor de normale gebruiker die even snel zijn account(gegevens) deelt.
En ja, dit zou een hacker waarschijnlijk ook kunnen misbruiken. Maar dan is het systeem al compromised dus dan zijn er waarschijnlijk al meerdere exploits nodig. Waarbij het nog steeds zo zal zijn dat de gebruiker fysiek interactie met het apparaat moet hebben (een Yubikey kun je 24/7 aansluiten, maar zolang je niet op het knopje op de sleutel drukt zal deze geen authenticatie doen).

Of, in dit geval, de FIDO2 & Webauthm standaarden iets van een timing component hebben ingebakken om "vertraging" te flaggen durf ik niet te zeggen.
Maar technisch zijn deze oplossingen natuurlijk sowieso al superieur aan OTP doordat het werkt op basis van public key cryptografie waarbij in het geval van een hardware generator deze ten eerste nooit de private key inzichtelijk kan/zal maken (de shared key bij OTP is dit wel, zit verpakt in de QR code en afhankelijk van de client app ook uit te lezen in tekst), en de private key is gekoppeld aan een website. Dus een phishing website kan nooit de Webauthn flow voor de echte website doorlopen simpelweg doordat het domein niet overeenkomt en de sleutel dus nooit iets zal doen met het authenticatie verzoek. Daar waar bij OTP de de phishing website de OTP code aan de gebruiker kan vragen en die gewoon de legitieme OTP code kan invullen de phishing website die kan "door zetten" naar de legitieme website.

Mijn werk gebruikt github voor interne projecten en verplichten 2fa om überhaupt toegang te krijgen tot de organisatie.
Onlangs een yubikey 5c NFC gekregen van een collega en het is echt ideaal voor 2fa. Natuurlijk ook een backupmethode mocht ik hem kwijtraken.
Wat dus ook vet is aan die yubikey is dat je hem kan gebruiken om git commits/tags te signen met gpg, zo krijgen je commits en tags een verified tag zodat mensen weten dat het echt jouw github account is.

Kan hem echt aanraden!

Tip, koop een 2de key en mirror gewoon alles wat je aan TOPT, certs, etc er op zet.
2de key in de kluis/schoenendoos.

Ben ik ook zeker van plan!

Goede zaak, je wilt niet weten hoeveel account hacks kunnen worden voorkomen door 2FA

Maar alleen 2FA is ook niet meer voldoende, MS gaat niet voor niets MFA met number matching forceren voor M365...

Voor MacBook gebruikers die twijfelen: Je kan de vingerafdrukscanner van je laptop als 2FA gebruiken. Kost je vrijwel geen tijd vergeleken met het overtikken van een TOPT code

edit:
(al zou ik wel een TOPT als 2e optie erin laten staan voor het geval dat je je laptop niet bij je hebt, maar je telefoon wel etc. etc.)

Hey kijk, een normaal bedrijf anno 2022.

Ondertussen bij Spotify: "Hu,wat is 2FA?"

De kosten/baten analyse van MFA zal bij dat soort diensten negatief zijn. De meeste gebruikers vinden het maar lastig en vermijden het als ze kunnen. Het kost geld om het te implementeren en te onderhouden. En die paar gebruikers die het wel willen zijn niet bereid de kosten daarvoor te dragen.

Spotify heeft wel 2FA voor artiesten: https://artists.spotify.c...ticle/2-step-verification

Ik ben benieuwd hoe lang het duurt dat een eigenaar zijn totp device kwijt is en een belangrijke repo niet meer in komt voor een bugfix of iets dergelijks...

Dat is dan ook het mooie van 2FA, je kan (meestal) extra factoren toevoegen om dat soort situaties te vermijden.

zip

[Reactie gewijzigd door Akufen op 17 december 2022 05:24]