GitHub gaat eind 2023 tweestapsverificatie verplichten voor alle ontwikkelaars

Eind 2023 moeten alle GitHub-gebruikers die bijdragen leveren op het platform tweestapsverificatie hebben ingeschakeld. De accounts van softwareontwikkelaars zijn regelmatig het doelwit van hackers, zegt het platform.

Volgens de statistieken van GitHub heeft slechts 16,5 procent van de actieve gebruikers tweestapsverificatie ingesteld. Ook het aantal npm-gebruikers dat gebruikmaakt van tweestapsverificatie is laag, ongeveer 6,4 procent.

"De meeste incidenten zijn niet het gevolg van aanvallen via zero days, maar van de diefstal of het lekken van wachtwoorden of andere manieren waarop aanvallers toegang krijgen tot de accounts van hun slachtoffers. Gehackte accounts kunnen worden gebruikt om code te stelen of schadelijke wijzigingen toe te voegen aan de code. Dit vormt niet alleen een risico voor de personen en organisaties die aan deze accounts zijn gekoppeld, maar ook voor alle gebruikers van de getroffen code", schrijft GitHub.

Wat de gevolgen zijn voor accounts die tegen eind 2023 geen extra beveiligingsmaatregelen hebben genomen, is nog niet duidelijk. De komende maanden gaat GitHub meer informatie geven over zijn plannen voor de verplichting van tweestapsverificatie.

Reacties (106)

[NullCrayfish]

Laat ik eens onpopulair doen door te zeggen dat ik dit jammer vind.
2FA is natuurlijk een fantastisch idee om de beveiliging op te krikken, maar het is ook erg hinderlijk/irritant in gebruik.
Ik zie het liever als optionele mogelijkheid zodat gebruikers die hun account belangrijk genoeg vinden ervan kunnen profiteren.
Mijn Github account bevat een handvol forks van projecten waar ik ooit eens een verbetersuggestie wilde aandragen en wat issues en comments. Wat mij betreft niets dat echt de hinder van 2FA rechtvaardigt.

De meeste accounts die ik heb kunnen me gestolen worden. Enkel voor de belangrijke accounts gebruik ik graag 2FA.

[Gustaaf437]

Het gaat natuurlijk niet alleen om jouw eigen veiligheid, maar ook die van anderen.
Stel: jij gebruikt jouw account voor een aantal pull-requests in een bepaald project en wordt daar op een zeker moment in vertrouwd. Je wordt daarna gehackt en vanuit jouw account wordt daarna een wijziging klaargezet en vertrouwd met een backdoor. Dan heb je daar niet alleen jezelf mee, maar een heel project en veel mogelijke slachtoffers. Ja, het is hinderlijk, maar helaas wel nodig.

[R4gnax]

Het gaat natuurlijk niet alleen om jouw eigen veiligheid, maar ook die van anderen.
Stel: jij gebruikt jouw account voor een aantal pull-requests in een bepaald project en wordt daar op een zeker moment in vertrouwd. Je wordt daarna gehackt en vanuit jouw account wordt daarna een wijziging klaargezet en vertrouwd met een backdoor. Dan heb je daar niet alleen jezelf mee, maar een heel project en veel mogelijke slachtoffers. Ja, het is hinderlijk, maar helaas wel nodig.

Github werkt op het moment al zo dat repositories geconfigureerd voor 2FA alleen toestaan om gebruikers als externe collaborators toe te voegen wanneer deze gebruikers ook 2FA op hun account aan hebben staan. En ze krijgen automatisch de bons mochten ze 2FA uitzetten.

Heel makkelijk om daar op door te bouwen door voor het indienen van een pull request naar een met 2FA beveiligde repository te vereisen dat je dat doet vanaf een account waar ook 2FA aanstaat.

En vervolgens kun je mensen die enkel wat eigen zooi online houden voor privè gebruik; of enkel een account hebben om bugs/issues te rapporteren of mee te praten over change requests, lekker met rust laten.

[svane]

Persoonlijk vind ik dat GitHub het vrij goed doet qua inloggen. Zodra je een keer (met 2FA) bent ingelogd, dan onthouden ze je browser voor een bepaalde tijd. Hoe lang dat precies is, zou ik niet meer weten, maar ik kan eerlijk gezegd niet meer herinneren wanneer ik voor het laatst opnieuw moest inloggen.

Als je vaak vanuit een nieuwe laptop/PC inlogt, dan kan het vervelend zijn, maar op die momenten is 2FA juist ook 't meest belangrijk.

Voor het veranderen van je wachtwoord (of het andere 'gevaarlijke' handelingen) is 2FA wel nog extra nodig, maar ook dat lijkt me niet echt een probleem.

Andere sites doen het wel een stuk slechter. Op sommige plekken moet ik minstens 1 keer per week opnieuw een code overtypen (vaak nog per mail verstuurd), erg irritant.

[MazDaMan1970]

Sorry hoor, maar "hinderlijk/irritant" komt op mij over als een stuk luiheid. 2FA is gewoon noodzakelijk & wat is nou het probleem om ff een authenticator App op jouw smartphone te gebruiken? Die paar seconden die je extra kwijt bent weegt niet op tegen de gevolgen van een beveiligingslek. Zelfs voor incidentele/niet kritische diensten, die 2FA als een optie aanbieden gebruik ik ten alle tijden 2FA.

[TheVivaldi]

Ik heb één keer zo'n app geprobeerd, te weten die van Microsoft, maar na verloop van tijd kon ik nergens meer inloggen omdat de codes geweigerd werden en nog enige tijd later waren al mijn sites in de app zelfs weg. Bij een paar sites ben ik mijn account volledig kwijt omdat er geen mogelijkheid is om 2FA te omzeilen, ook niet vanuit de ontwikkelaarskant.

Dus nee dank je, ik vertrouw die apps niet. Doe mij maar 2FA via sms of e-mail als het echt moet of het een heel vertrouwelijke site betreft, of gewoon geen 2FA.

[Hatsjoe]

Ik heb geen ervaring met de app van Microsoft, maar de app van Google is gewoon top, nooit problemen mee gehad.

Daarnaast kan je bij bijna alle sites die MFA via een app ondersteunen ook "recovery codes" krijgen. Dat zijn een set aan codes die je moet zien als een eenmalig te gebruiken wachtwoord die je invult in plaats van je normale MFA code. Op die manier kan je altijd nog inloggen wanneer je MFA device kwijt of kapot is.

Bovendien kan je zelf ook gemakkelijk de MFA "secret" opslaan/back-uppen zodat je op een nieuw apparaat je MFA simpel weer opnieuw kan opzetten. Alternatief kan je een dienst als Authy gebruiken, alhoewel valt daarmee het hele nut/idee van MFA wel weer te betwisten.

MFA via SMS en e-mail is absoluut niet veilig en zou daardoor ook never nooit ondersteund of geïmplementeerd moeten worden.

[MazDaMan1970]

Ik gebruik beide authenticators, zowel die van Google & Microsoft. In die 2 jaar tijd dat ik ze nu gebruik ben ik nog nooit tegen problemen aangelopen. En mocht ik desondanks tegen authenticatie-problemen aanlopen, heb ik nog altijd een fallback.

[Devalno]

Hoe hinderlijk 2FA is hangt wel af van hoe het is geimplementeerd. Als je login op hetzelfde apparaat voor een langere periode wordt onthouden, hoef je maar heel af en toe weer in te loggen en je 2FA te gebruiken. Als je dat hooguit eens per week (of nog minder vaak) hoeft te doen, valt het toch wel mee met hoe hinderlijk het is?

[Barsonax]

Zo hinderlijk is het nou ook weer niet. Hoe vaak moet je dit nou doen? GitHub onthoudt dit namelijk gewoon.

Zodra je ook maar iets van noemenswaardige contributies maakt op GitHub ben je al interessant voor hackers om malafide code ergens binnen te krijgen.

Ik heb bijv meegewerkt aan de Duality game engine. In principe kan mijn account daar malafide code in committen en vervolgens kan je daarmee alle gebruikers van Duality mee aanvallen. Ik weet wel zeker dat hackers daar in geïnteresseerd zijn.

[dieAndereGozer]

Ach, je beschermd er ook je mede devs mee en de gebruikers van die software. Dat je daarom 1 keer in je leven een 2FA moet invullen, jammer dan. Dan zoek je toch een ander platform?

[moonlander]

Ik snap dan niet waarom dat zolang moet duren. Eind 2022 is toch ook prima te doen? Nog een dik half jaar de tijd.

[CH4OS]

Je kunt 2FA al instellen. Dus als het werkelijk een issue is, kun je het nu al zonder problemen instellen. Vanaf 2023 wordt 2FA echter verplicht. Hoewel dat op zich ook best sneller zou kunnen inderdaad, zullen er vast ook redenen zijn waarom gebruikers en vooral bedrijven bijvoorbeeld, meer tijd nodig zijn hiervoor.

Denk bijvoorbeeld aan CI/CD processen die anders niet meer kunnen voltooien. Of dat best practice is, laat ik even in het midden (het antwoord laat zich raden... ), maar het zou mij niet verbazen als er partijen / repo's zijn waarop dit op deze manier gebruikt wordt. Dat moderniseren hoeft ook niet veel tijd te kosten inderdaad, maar dat betekend niet dat die ruimte/tijd er nu ook is voor die partijen die dit op deze manier gebruiken. Dan is wat meer tijd wel fijn om te hebben en gewoon netjes van GitHub/Microsoft in dit geval.

CC: @PdeBie

[Reactie gewijzigd door CH4OS op 22 juli 2024 14:52]

[Sando]

Denk bijvoorbeeld aan CI/CD processen die anders niet meer kunnen voltooien.

Een probleem is bijvoorbeeld dat een pull van een publieke repo wel zonder account kan, maar dat veel bedrijven hun repositories logischerwijs privé hebben staan en dan via een script inloggen om geautomatiseerd te kunnen pullen.

Je kunt natuurlijk gewoon rsa keys gebruiken en pullen over ssh, maar dat hergebruik van keys op verschillende VPSes van derden schijnt ook weer afgeraden te worden.

Het artikel op Github geeft niet direct een best practice antwoord op deze en andere vragen, maar lijkt te suggereren dat ze zelf ook nog een beetje zoekende zijn.

GitHub is committed to making sure that strong account security doesn’t come at the expense of a great experience for developers, and our end of 2023 target gives us the opportunity to optimize for this. As standards evolve, we’ll continue to actively explore new ways of securely authenticating users, including passwordless authentication.

Daarom eind 2023.

[Reactie gewijzigd door Sando op 22 juli 2024 14:52]

[Gopher]

Misschien willen ze meer mensen op Github actions krijgen? Op zich een prima oplossing, de workers hebben uiteraard access tot hun eigen repo, ik geloof niet dat wij iets extras doen met authenticatie daar, behalve misschien wat GC spulleboel.

Wel wat lastiger als je wat meer dingen helemaal in eigen controle wilt hebben, maar als je de build processen van github niet vertrouwd, is het misschien ook beter om je eigen repositories te hosten via een Gitlab of iets dergelijks?

Ik vind 2FA niet altijd leuk, maar als het werkt zoals 't nu al een tijd werkt, dan hoef je dat ook maar zeer zelden daadwerkelijk te gebruiken voor je web login en gebruiken we lokaal gewoon RSA+SSH.

[CH4OS]

Een probleem is bijvoorbeeld dat een pull van een publieke repo wel zonder account kan, maar dat veel bedrijven hun repositories logischerwijs privé hebben staan en dan via een script inloggen om geautomatiseerd te kunnen pullen.

Snap ik, dit is precies waar ik op doelde, maar dat eigenlijk een beetje impliceren wilde, omdat er legio oplossingen en/of redenen zijn.

Je kunt natuurlijk gewoon rsa keys gebruiken en pullen over ssh, maar dat hergebruik van keys op verschillende VPSes van derden schijnt ook weer afgeraden te worden.

In de meeste, moderne, pipelines kun je secrets bewaren. Key-value pairs die encrypted opgeslagen worden, qua opslag van de gegevens zit het dus wel goed.

[Reactie gewijzigd door CH4OS op 22 juli 2024 14:52]

[GekkePrutser]

CI/CD processen authentificeren zich niet via 2FA. Die moeten immers geautomatiseerd kunnen draaien en dan is wachten op een 2FA code niet zo handig Dan is het niet zo 'continuous' meer. Daar gebruik je app secrets voor.

Om die te genereren moet je natuurlijk wel inloggen op de website en dat moet dan met 2FA. Maar ik kan me niet voorstellen dat reeds gegenereerde secrets opeens onbruikbaar worden gemaakt?

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 14:52]

[CH4OS]

CI/CD processen authentificeren zich niet via 2FA. Die moeten immers geautomatiseerd kunnen draaien en dan is wachten op een 2FA code niet zo handig Dan is het niet zo 'continuous' meer. Daar gebruik je app secrets voor.

Dat is precies waar ik op doel inderdaad. Maar er zullen vast meer en/of andere redenen hiervoor zijn, vandaar dat ik het wat algemeen liet.

Om die te genereren moet je natuurlijk wel inloggen op de website en dat moet dan met 2FA. Maar ik kan me niet voorstellen dat reeds gegenereerde secrets opeens onbruikbaar worden gemaakt?

De 2FA op basis van TOTP-tokens zijn time-based. Dus afhankelijk van de tijd heb je middels een secret een bepaalde code die eruit komt. Mocht je het dirty willen doen, kun je dus eventueel de TOTP automatiseren, mits je de secret dan in het script opneemt. Wat natuurlijk totaal niet safe is, uiteraard.

[R4gnax]

Je kunt 2FA al instellen. Dus als het werkelijk een issue is, kun je het nu al zonder problemen instellen. Vanaf 2023 wordt 2FA echter verplicht. Hoewel dat op zich ook best sneller zou kunnen inderdaad, zullen er vast ook redenen zijn waarom gebruikers en bedrijven bijvoorbeeld, meer tijd nodig zijn hiervoor.

Ik vraag me vooral af hoe MS van plan is de use-case voor remote work op te lossen icm een hardware-sleutel ipv hun mobile app via de privé telefoon te moeten gebruiken.

FIDO hardware sleutels moet je in een USB poort prikken. Veel plezier met je RDP of soortgelijke remote sessie. Daarvoor zul je connected USB devices van de client naar de host moeten kunnen forwarden. Dat is ook niet zonder security issues. En je remoting tool moet dat ook maar net ondersteunen. En het moet ook nog maar eens zijn dat het communicatiekanaal in software tussen de driver voor de hardwaresleutel en de programma's die er mee mogen praten niet ook nog eens op bepaalde manieren door het OS afgeschermd worden waardoor deze verbinding niet naar de remote host gebrugd kan worden.

[CH4OS]

Yubikeys kunnen zelfs worden gebruikt voor het ontgrendelen / beschikbaar stellen van LVM-partities, ik zie dus niet waarom een hardware key niet zou kunnen werken.

[hahaha2223]

Ze zijn blijkbaar nogal traag bij github, zo is er ook nog steeds geen ipv6 toegang.

[KoffieAnanas]

2FA is al een tijdje mogelijk. Het is alleen nog niet verplicht.

[djiwie]

2FA zelf is al jaren mogelijk (en kun je als organisatie ook verplichten voor members).

[PdeBie]

Inderdaad. Hoeft toch niet heel ingewikkeld te zijn.

[bones]

Wij delen een account, dat zal dan straks lastiger gaan worden.

[turbojet80s]

Kijk eens naar Authy van Twillio. Wij gebruiken deze tool voor de gedeelde MFA tokens.

[CH4OS]

Ik vind het een eng idee om de TOTP tokens bij een derde partij te hebben, die ze vervolgens in de cloud heeft staan, waar je zelf geen invloed op hebt. Ik heb Authy jaren gebruikt, tot ik me realiseerde dat ik de TOTP-tokens niet bij een derde partij wilde hebben waar ik er verder geen invloed op heb.

Ook gebruik ik tegenwoordig een password manager, die ook gewoon TOTP-codes kan. Ik gebruik daarom Enpass en de database wordt (nu althans) op een cloud storage opgeslagen, maar ik heb daar wel de controle over. Als ik het verwijder, is het daar weg. Als ik het overzet ook. Enpass kan daarnaast ook overweg met bijvoorbeeld Nextcloud of webdav, dus het heeft echt mogelijkheden te over om de database op te slaan. Met de verschillende apps verbind je dan ook naar die database en heb je dus altijd en overal dezelfde passwords en zelfs TOTP-tokens.

In dat op zicht kan dat voor @bones dus ook een prima oplossing zijn om 2FA te hebben en toch het account te kunnen delen.

[Reactie gewijzigd door CH4OS op 22 juli 2024 14:52]

[Zer0]

Je TOTP bij een andere partij is vergelijkbaar met een passwordmanager bij een andere partij gebruiken, redelijk veilig als je een goede gebruikt. Je moet echter niet beide bij dezelfde partij neerleggen.
Het hele idee achter 2FA is dat je minimaal twee factoren moet hebben, als er één uitlekt mag dat geen probleem zijn.
Imo is jouw stap naar een enkele database met zowel de wachtwoorden en de TOTP-tokens een stap terug in veiligheid.

[Reactie gewijzigd door Zer0 op 22 juli 2024 14:52]

[CH4OS]

Snap ik, maar ik heb liever de controle over dergelijke gegevens. Dan heb ik nu alles bij elkaar en is dat misschien ook niet helemaal veilig, maar dat is beter dan wat ik had (geen password manager en TOTP in Authy). Ik moet nog even kijken of ik bijvoorbeeld een Yubikey kan gebruiken als 2FA voor het unlocken van mijn Enpass.

[Yggdrasil]

Ik doe hetzelfde maar dan in Bitwarden. Ondersteund ook TOTP en Yubikey. Bitwarden kun je ook zelf draaien als je hun cloud niet vertrouwd en er zijn zelfs forks van de server gemaakt door derden als je nog meer opties wilt. Ikzelf vertrouw hun cloud versie wel en betaal er graag iets voor.

[Blokker_1999]

2FA heeft niet alleen als doel dat je 2 factoren hebt, maar dat je ook 2 verschillende factoren hebt. Als je alle twee in een (verschillende) wachtwoordmanager steekt, heb je daarna nog altijd maar 1 enkele factor die je data beschermd omdat ze alle twee zitten weggestoken achter een master wachtwoord. Er zijn uiteindelijk maar 3 factoren waauit je kunt kiezen (sommige zeggen 4) en voor echte MFA heb je er minstens 2 van nodig:
- something you know : username and password
- something you have : smartphone with authenticator app
- someone you are : biometric verification (bijv. voor de smartphone te unlocken)

heb je dus een authenticator app op je smartphone voor TOTP en ontgrendel je die met je vingerafdruk of gezichtsherkenning dan voldoe je al heel snel aan MFA met 3 factoren.

De laatste factor die soms genoemd wordt is "somewhere you are", maar die is het eenvoudigste om te vervalsen.

[R4gnax]

something you have : smartphone with authenticator app

Zout op slakken; maar technisch gezien is een smartphone met authenticator app niet een 'something you have.'

Het idee is dat het een 'something only you have' is en dat vervalt met een internetverbonden apparaat; elk internetverbonden apparaat, wat voldoende 'open' is voor general purpose computing. Als het niet airgapped is; of niet compleet dichtgetimmerd met een strikt gelimiteerd functieoppervlak, moet je het in principe zien als hackbaar en daarmee niet langer iets waar alleen jij toegang tot hebt.

[Reactie gewijzigd door R4gnax op 22 juli 2024 14:52]

[z1rconium]

Het gebruik van webdav lijkt me een stuk enger.

[Blokker_1999]

En laat me raden, het wachtwoord voor die accounts staat er dan ook direct bij waardoor je weer van MFA bent gedowngrade naar SFA ...

Kwam recent zo ook een product tegen waar onze CISO een presentatie van had gekregen. Ging eens kijken op de website en ze kwamen ook direct af met dat je met hun product overal SSO kon gaan doen, zeer gebruiksvriendelijk waarop ik direct tegen onze CISO stelde dat je een bedrijf dat zoiets doet, en in essentie de MFA dus uitschakeld, toch nooit serieus kunt nemen op security gebied. Hij gaf me ook gelijk.

[turbojet80s]

Bedoel je te toevallig Teamleader? Daar kun je out of the box geen MFA inschakelen. Hun helpdesk adviseert nou net om SSO in te schakelen als je MFA wilt ... Dat vind een ernstige zaak inderdaad. Maar SSO sluit het gebruik van MFA dus niet uit. Ik weet alleen niet of je dat kunt afdwingen. Iemand die dat weet?

[Reactie gewijzigd door turbojet80s op 22 juli 2024 14:52]

[batjes]

Geen idee hoe Github de 2FA doet, maar vaak wordt er gebruik gemaakt van een code die op meerdere apparaten in te stellen is.

[Hatsjoe]

Ik kan letterlijk 0 redenen bedenken om een account te delen, dus ben oprecht nieuwsgierig waarom jullie een account delen. Welk probleem/limitatie probeer je op deze manier op te lossen?

[joker1977]

Ik kan niet spreken voor @bones - maar misschien is het feit dat er betaalde features zijn op Github een reden? Op https://github.com/pricing zie je de extra mogelijkheden die een betaald account biedt.

Mogelijkerwijs gebruiken ze 1 betaald account en wordt dat gedeeld door meerdere gebruikers ?

[Gubbel]

Dat is tegen de voorwaarden en dus geen medelijden als het delen dan lastig wordt.

[joker1977]

Geen idee of het tegen de voorwaarden is (klinkt wel logisch, maar ik heb de voorwaarden niet gelezen).

Neemt niet weg dat dat een mogelijke reden is om te account-sharen.

[P1nGu1n]

Waarom zou je een account delen? Je kunt met 2 accounts ook in één repo werken.
Daarnaast kan je TOTP configureren op twee apparaten tegelijk, dus zelfs met een gedeeld account hoeft het geen probleem te vormen.

[Sando]

Zelfde reden als waarom mensen hun Netflix account delen.

[Ablaze]

Iets als TOTP kun je ook met twee mensen gebruiken. Je scant gewoon beiden de QR code met de key, die je in het begin krijgt.
Of het delen van Github verder handig is, is een ander verhaal.

[Reactie gewijzigd door Ablaze op 22 juli 2024 14:52]

[Sfynx]

Niets houdt je tegen de tweede factor op meerdere apparaten in te stellen natuurlijk.

[CasEbb]

"@JudithEnBas approved this pull request."

[PdeBie]

JudithOrBas zou dan beter zijn

[Arrogant]

JudithAndOrBas

[Z100]

Kijk eens naar Yubikeys. Zijn hardware tokens. Je kan meerdere keys aan een account koppelen.

[Gamebuster]

De QR code die je scant zodat je daarna die 6-cijfigere codes kan genereren? Die is statisch. Het is gewoon een URL met een secret erin. Maak een screenshot van die QR code, en je kan 'm aan zoveel apps toevoegen als je wenst, nu en in de toekomst. Ook handig als "backup" voor als je bijv. je telefoon kwijt raakt, want die 2FA secrets worden soms niet meegenomen in telefoon backups (om voor mij onverklaarbare rede)

URL ziet er bijv. zo uit:

otpauth://totp/Example:[e-mail]?secret=JBSWY3DPEHPK3PXP&issuer=Example

De secret + huidige tijd + optionele settings worden gebruikt om een code te genereren. Alle andere informatie is enkel informatief.

https://datatracker.ietf.org/doc/html/rfc6238#section-4

[Reactie gewijzigd door Gamebuster op 22 juli 2024 14:52]

[bones]

Thanks dat wist ik niet, gaan het zo proberen.

[dieAndereGozer]

Je kan toch je TOTP key delen?

[Keypunchie]

Hoop dat ze dat bedoelen voor inloggen in de webinterface en (vervolgens) account zaken regelen, voor push/pull kun je toch hopelijk een token blijven gebruiken.

[pizzafried]

of ssh keys.

[xvilo]

Gelukkig worden die minder snel verhandeld

[GekkePrutser]

Ja inderdaad want die kan je op een Yubikey opslaan waardoor de private key gewoon niet te kopieren is. Wordt op de key gegenereerd en kan er niet af. Je kan alleen bewijzen dat je hem hebt.

Op een OpenPGP kaart kan ook.

Dat is het voordeel van die dingen: Het is ook een vorm van 2FA. Het token + de pincode zijn de twee factoren.

[divvid]

Dat hoop ik ook, 2fa is echt af en toe een verschrikking, ook al is het noodzakelijk

[2Keys]

Lijkt me een goed plan. Github is best een vitaal stuk infrastructure geworden, op ze mist 2fa maakt dat voor iedereen wat veiliger.

[Martinspire]

Daarom is het ook interessant wat ze 2023 gaan doen met gebruikers die kritische packages onderhouden en 2FA niet instellen.

[Devalno]

Volgens mij doel je op de mogelijkheid dat daardoor kritische packages straks wellicht niet meer onderhouden kunnen worden.
Als dat inderdaad zo is: een aanpak die dat kan voorkomen is om die gebruikers wel nog te laten kunnen inloggen voor het instellen van 2FA, maar dat alle andere functionaliteiten geblokkeerd zijn totdat je de 2FA hebt ingesteld.
Dan gaat er niks verloren en kan het door iedereen alsnog ingesteld worden. Of denk je dat er gebruikers zijn met bezwaren tegen het gebruik van 2FA?

[DonJunior]

.. Of denk je dat er gebruikers zijn met bezwaren tegen het gebruik van 2FA?

Die zijn er vast wel ja.. Tegenwoordig moeten mensen overal iets van vinden en valt over alles wel een complot te bedenken.
Grote kans dat straks iemand roept "Dit was altijd al het grote plan van Microsoft"
Ongeacht welke fundering laat staan redenering.

Edit: Ik had nog niet alle reacties gelezen vanochtend, maar een dergelijke reactie was er al:

2FA is Schijn veiligheid

Het is wel weer een extra stap wat het moeilijker maakt
maar als iemand echt toegang wil kan het nogsteeds

..
Daarnaast zijn er vast mensen die 2FA niet willen. 2FA betekent ook minder privacy.

Door: Larry4 in 'GitHub gaat eind 2023 tweestapsverficatie verplichten voor alle ontwikkelaars'

[Reactie gewijzigd door DonJunior op 22 juli 2024 14:52]

[kozue]

Ja. Ik. Ik ben tegen het koppelen van van alles en nogwat aan een smartphone. Smartphones zijn dataminers en worden massaal misbruikt door bedrijven en overheden om persoonlijke informatie over jou bij te houden. Ik heb er nog wel een, maar zou m graag een keer wegdoen en terug naar een telefoon zonder app platform, die alleen kan bellen, smssen en webbrowsen. Dus alles wat ik er aan zou moeten koppelen is een stap in de verkeerde richting. Dat doe ik dus niet. Ook het afgeven van een telefoonnummer voor apploze sms verificatie doe ik niet aan. Ik geef nergens mijn nummer tenzij ik denk dat iemand dat nodig heeft. En hebben de meesten er wel eens aan gedacht hoe ze hun account binnen komen als ze hun telefoon verliezen?

De meeste 2FA werkt alleen via smartphones. Daarom krijg ik de kriebels als ik ergens 2FA hoor. Ik heb ook 1 keer een systeem gezien met tokens die via email worden verstuurd, maar volgens mij is dat zeldzaam. Als het verplicht wordt in github, gebruik ik gewoon geen github meer. Op m’n werk hebben we een eigen prive gitlab, dus ik heb alleen een persoonlijk github account. Ik heb er een paar projectjes op gezet die ik gemaakt had voor m’n werk en nuttig kunnen zijn voor anderen. Die zet ik dan lekker op gitlab, dus die anderen hebben dan lekker pech.

[Gps4l]

Bezwaren, heb ik misschien wel.

Ik heb geen smart phone, en was ook niet van plan er eentje aan te schaffen.
Ik loop al op een aantal andere sites tegen dit probleem aan.

Een simpele oplossing zou volgens mij zijn, dat ik me gewone telefoon nummer kan gebruiken.
Geen 06 dus. En ja ik heb een github account.

[markjanssen]

toepasselijke username

[Frij5fd]

Ik werk met Github voor de apps die ik voor Garmin horloges maak. Via egit worden updates die ik in Eclipse maak doorgestuurd. Ik werk met Ubikeys, ook voor Github. Voor het configureren van egit moest ik echter een token aanmaken, waarmee er feitelijk weer sprake is van 1FA. Het is wat beter dan alleen een wachtwoord, maar geen echte 2FA natuurlijk. Of zie ik dat verkeerd?

[crazyboy01]

Nee, dat zie je goed. Van wat ik me herinner kun je wel de specifieke permissies toewijzen aan zo'n token, en die token gebruikte ik vervolgens in plaats van mijn oude wachtwoord in de terminal. Bij de meeste e-mailservices gaat het bv ook zo als je een 2FA beveiligde mailbox in een third party mailclient wilt instellen.

Door de permissies is het dan niet helemaal hetzelfde als volledige toegang via een wachtwoord zonder 2FA, maar je gaat in mijn ogen inderdaad in de basis gewoon weer terug naar enkel een moeilijk wachtwoord. Het lijkt het populairste alternatief op dit moment om 2FA niet de ondersteuning voor apps van derden te laten belemmeren, wanneer die geen 2FA begrijpen.

Opzich zit je met zo'n token trouwens aardig safe: als de website lek is, is 2FA ook weinig waard, en zo'n token gaan ze niet raden. Daarnaast is het de bedoeling dat je voor iedere app een eigen token aanmaakt met de juiste permissies, die dus ook gemakkelijk te blokkeren en verversen zijn. Maar een echte extra stap blijft dan inderdaad uit en de token zou in theorie gestolen kunnen worden, zeker als je deze vaker intypt dan een keer.

[Yggdrasil]

Het voordeel van een token boven een wachtwoord is dan wel dat tokens vaak erg lang en complex worden gemaakt terwijl wachtwoorden nog te vaak relatief kort en simpel zijn omdat mensen ze willen kunnen onthouden.

Daarnaast kan een token beperkte toegang krijgen, bijv. alleen read-write tot een repo en niet de mogelijkheid om account settings aan te passen, etc., of voor een beperkte tijd.

Door per applicatie een apart token aan te maken kun je makkelijker zien waar ongeautoriseerde toegang vandaan is gekomen en die toegang intrekken.

[spokje]

offtopic:
Ben ik de enige die echt weinig can Github begrijpt? altijd als iemand een linkje stuurt van een fantastisch project en de link is Github zak ik altijd een beetje door de grond ofzo. Snap echt weinig van die site. Just give me the setup.exe

[Keypunchie]

Dat komt denk ik omdat je zelf geen software-ontwikkeling doet.

Github host de broncode, niet het eindproduct (een executable).

Zelf moest ik daar ook erg aan wennen. Op zich gebruiken ze doorgaans standaard tooltjes om van de code een executable te maken, maar je moet het maar net weten.

[spokje]

Ja precies ik zit nu te stoeien hoe ik een docker container vanaf github op m'n Synology (via gui) krijg. Al wat uurtjes en Google ingestoken maar nog steeds niet voor elkaar. En alle topics die je op internet vindt gaan eigenlijk altijd over de cli. Dat soort dingen is met github altijd wel een uitdaging voor mensen die bang zijn voor cli zoals ik (op een knopje rammen geeft een veiliger gevoel dan een riedeltje code intikken en je het gevoel hebt dat je de helft misschien wel mist. Terwijl je weet dat een knop niets anders is dan een commando die op de achtergrond wordt uitgevoerd maar toch

[xFeverr]

Staat die docker image zelf niet gewoon op docker hub? Dan hoef je de image zelf niet te builden.

[spokje]

Ja staat er wel op, maar ik zou 'm graag via de gui in m'n Synology nas inladen maar dat lijkt niet te kunnen helaas. Weet nog niet hoe ik 'm via cli in het systeem krijg.

[aikebah]

Als hij op dockerhub staat zou je die langs die GUI op je synology moeten kunnen krijgen.

Denk dat https://www.youtube.com/watch?v=xzMhZoUs7uw je wel verder moet kunnen helpen

[spokje]

Thanks. Ga ik ff checken 👍🏻

[kozue]

Ik heb het andersom. Met een commando zie je exact wat de opdracht is die je het systeem geeft. Met een knopje moet je maar afwachten wat voor functie er achter de omschrijving van meestal slechts 1 woord zit.

En voor de wat exotischere functies is een GUI helemaal een drama. Moet je zoeken in lange menu’s of configuratieschermen waar die ene functie ook alweer zat, terwijl een commando copy pasten altijd werkt.

[spokje]

Je hebt helemaal gelijk, alleen heeft dit denk ik ook met de technische kennis van mij te maken er zit gewoon geen developer bloed in me

[Jeoh]

Op GitHub kan je ook steeds vaker de releases met executables vinden, gelukkig.

[Gamebuster]

Nee, zeker niet. Je zoekt naar een tabje "Releases", en daar moet je zoeken in de bagger naar een .exe installer.

Het platform is ontworpen voor ontwikkelaars, niet voor end-users, maar dat weerhoudt ontwikkelaars niet om het ook gewoon aan gebruikers te delen. Luiheid want github biedt ook de mogelijkheid om gratis een website te hosten, waar je gewoon een simpele en gebruikersvriendelijke download link kan maken

[dieAndereGozer]

Geen last van. Github host broncode, die je nog moet compileren.
Daar zijn altijd instructies bij.
Ook hosten ze vaak zelf gecompileerde releases.

En bij cryptomining is het zelfs dat ze geen code beschikbaar stellen maar wel de release.

[Larry4]

2FA is Schijn veiligheid

Het is wel weer een extra stap wat het moeilijker maakt
maar als iemand echt toegang wil kan het nogsteeds

- Je telefoon kan nog steeds worden overgenomen om de 2e factor te bevestigen.

- Je kunt ook met een speciale attack gewoon de gebruiker van de telefoon jouw 2e factor bevestiging
door direct op het zelfde moment een authenticatie op te zetten als de gewone gebruiker toegang wil.
Hierdoor krijg de gebruiker 2x een 2FA melding maar meestal wordt er toch wel 2 keer op bevestiging geclickt. bijv door het netwerk te verstorened. dat het lijkt dat het langzaam gaat. zodat de gebruiker niks door heeft maar ondertussen heeft de hacker toegang.

Daarnaast zijn er vast mensen die 2FA niet willen. 2FA betekent ook minder privacy.
Mogelijk gaan hierdoor meer mensen weg bij GitHub naar alternatieve platformen

[R4gnax]

Je telefoon kan nog steeds worden overgenomen om de 2e factor te bevestigen.

Alleen als je een 2FA app gebruikt die niet beveiligd is met bijv. een vingerafdruk voordat er een one-time code gegenereerd wordt.

Je kunt ook met een speciale attack gewoon de gebruiker van de telefoon jouw 2e factor bevestiging door direct op het zelfde moment een authenticatie op te zetten als de gewone gebruiker toegang wil.
Hierdoor krijg de gebruiker 2x een 2FA melding maar meestal wordt er toch wel 2 keer op bevestiging geclickt. bijv door het netwerk te verstorened. dat het lijkt dat het langzaam gaat. zodat de gebruiker niks door heeft maar ondertussen heeft de hacker toegang.

En dat is te voorkomen middels protocollen zoals FIDO UDF waar de authenticatie domeingebonden is en door het apparaat simpelweg niet afgegeven wordt als de browser of applicatie aangeeft dat er sprake is van een ander domein.

Desalniettemin, hier heb je gewoon gelijk:

Daarnaast zijn er vast mensen die 2FA niet willen.

Niet willen; of niet kunnen.
Zullen vast nog wel mensen zijn die wel spul op Github hebben staan, maar bijv. geen compatible smartphone hebben; geen hardware key hebben; etc. en de kosten van aanschaf het niet waard vinden. Of mensen die gewoon niet nog een 2FA koppeling er bij willen hebben voor alleen maar een klein privè ding. Of mensen die op Github enkel een account gebruiken om bugs te rapporteren; over change requests mee te praten; etc. en waar compleet nul-komma-nul waarde zit aan ook nog eens de overhead van 2FA.
En ga zo maar door.

En wat te denken van bijv. gebruikers die remote werken en via RDP of soortgelijke protocollen verbinden op een client? Hoe wil je die bijv. laten samenwerken met een lokale hardware security key? Gaat niet lukken zonder dat er sprake zou zijn van een passthrough van connected USB peripherals tussen het host en client systeem in de remote sessie. En dat an sich is ook een security risico.


Nee, klakkeloos 2FA afdwingen voor iedereen is gewoon 'de nucleaire optie' en het dan pogen voor te doen als een universele verbetering, dat is inderdaad schijnveiligheid; in de zin dat het gewoon domweg virtue flagging voor de bühne is zonder aandacht voor verschillende use-cases.

Een meer praktische oplossing die dit wel heeft, kan veel simpeler zijn:
Alle repositories waarbij alle accounts met schrijf- en beheerrechten uitgerust zijn met 2FA een nette 'developer access secured with 2FA' badge geven.
Niet zonder precedent voor Microosft. Het is namelijk een beetje zoals ze ook met VS Code extensions gedaan hebben; waar er een verificatie mechanisme is gemaakt wat aantoont dat een ontwikkelaar ook echt eigenaar v/e extension is, zodat je als eindgebruiker minder makkelijk te maken krijgt met een supply-chain attack middels een swap-out.

[Reactie gewijzigd door R4gnax op 22 juli 2024 14:52]

[Gamebuster]

Wat een drama zeg, dan genereer je die 2FA codes toch gewoon op je computer? Je bent niet verplicht het op een telefoon te installeren.

https://winauth.github.io/winauth/download.html

[R4gnax]

En vervolgens ben je terug bij stap 0 en had je net zo goed 2FA niet aan kunnen hebben staan.
Cq het draagt niets meer bij en is verworden tot alleen maar een last. Een extra hoepel om door te springen.

[Reactie gewijzigd door R4gnax op 22 juli 2024 14:52]

[MartysmartySE]

Of je gebruikt hier hardware tokens voor. Dat heeft ook geen privacy issues

[R4gnax]

Of je gebruikt hier hardware tokens voor. Dat heeft ook geen privacy issues

Klopt. Maar de vraag is of die dus werken in bijv. een scenario waar je te maken hebt met remote work. Het is allemaal best een complex vraagstuk en door 2FA botweg te gaan vereisen stapt MS er met een gestrekt been in.

Maar goed; het is niet alsof ze dat niet eerder gedaan hebben met bijv. Windows 10 en het afdwingen van updates, initieel op de meest onpasselijke momenten en dat had je maar te vreten. Of nu weer met Windows 11 onder het mom van security über alles oudere hardware die nog perfect levensvatbaar is, gedwongen afrangeren.

Bedrijfscultuur en niet verder kijken dan je eigen tech-bubble groot is, denk ik.

[Yggdrasil]

Natuurlijk niet. Het draagt wél iets bij, namelijk een behoorlijke extra horde voor een aanvaller. Naast je uitgelekte wachtwoord moet een aanvaller ook opeens je computer gaan binnendringen. Of ga je nou zeggen (zoals ik uit je reacties opmaak) dat een tweede factor direct waardeloos is zodra er ook maar de kleinste mogelijkheid is om het te omzeilen?

Het maakt niet zo heel veel uit waar je die 2FA codes genereert, als ze maar niet samen met je wachtwoord uitlekken. Een aanzienlijk aantal inbraken komt tegenwoordig door ongeautoriseerde toegang tot broncode repo's en 2FA is een bewezen beveiligingsmethode.

[Gamebuster]

Hoe kom je daar nou bij? Je bent alsnog beschermd voor wanneer iemand je wachtwoord achterhaalt (om wat voor rede dan ook). Het maakt echt geen verschil of het op je telefoon staat of op je computer.

[Blokker_1999]

En hoe is dit schijn veiligheid?

Ja, je telefoon kan overgenomen worden, maar dat is weer een extra apparaat dat men moet zien over te nemen. Vergeet niet dat je bij een correct gebruik van MFA meerdere factoren hebt. Die telefoon met zijn authenticator is er daar maar 1 van.

[dieAndereGozer]

2FA is Schijn veiligheid

Daar ben ik het niet mee eens.

Want je moet naast de inlog creds ook nog iemands telefoon / apparaat hacken.

Het lijkt mij goed mogelijk dat als je echt super secure bezig bent, dat je een telefoon in airplane mode hebt, hack die dan maar eens vanaf afstand.

[Larry4]

Het is moeilijker maar theoretische mogelijk

btw in airplane mode werkt 2FA niet (wel met een kabeltje)

Eigenlijk komt het er op neer als je laptop/telefoon verbonden is met Wifi die ooit verbonden is met een open access point 2FA niet meer veilig is

maar wel via kabeltje of 4G/5G
(iig niet met de exploits via wifi)

[dieAndereGozer]

2FA werkt zeker wel met airplane mode, TOTP zijn gebasseerd op tijd, die codes kan je zo ver tikken.

[Bor]

2FA betekent ook minder privacy.

Waarom denk je dat dit zo is?

[Larry4]

2FA betekent vaak dat je als 2e Factor een app op je telefoon heb.
Hierdoor geef je vaak je locatie gegevens prijs. de 2FA app kan ook meer informatie doorsturen dan nodig is. (IP/ Wifi accespoints, etc)

Andere mogelijkheid is bijv email als 2e factor met een code. hierdoor geef je IP / Email adres prijs.
met de gevolden van dien.

Mogelijk met een token generatie is het wel anoniem. omdat er geen andere verbinding is.

[Bor]

2FA betekent vaak dat je als 2e Factor een app op je telefoon heb.

Dat hoeft helemaal niet. Een hardware token is een alternatief.

Hierdoor geef je vaak je locatie gegevens prijs

Nee hoor. Die rechten heeft een mfa app helemaal niet nodig.

[Reactie gewijzigd door Bor op 22 juli 2024 14:52]

[Tadango]

Zucht, weer meer sms'jes....

[dieAndereGozer]

Wie gebruikt 2FA met smsjes? Alles die een totp app.

[Tadango]

Ik gebruik alleen maar sms. Telefoon resetten en veel gedoe met alle apps, nee bedankt.

[dieAndereGozer]

Ik heb gewoon een encrypted backup van alle TOTP keys, die maakt andOTP voor je on demand. Met google authenticator staat er een kopie in de cloud, want ik eng vindt(naast dat ik geen gapps heb).

[Bor]

Ik zou je toch afraden om SMS te gebruiken. Het is een van de minder veilige manieren om een token te ontvangen. Zoek bv op simswapping etc. Het is niet voor niets dat meerdere toonaangevende bedrijven en initiatieven adviseren hier van af te stappen.

[Tadango]

Simswapping gebeurd niet snel, dan moet je wel iets belangrijks beheren / zijn. Dat risico loop ik niet

[Bor]

Dat je iets belangrijks moet beheren of zijn is een enorme misvatting. Een simswap is juist een relatief makkelijke manier om te "hacken". Het hacken van mensen is veelal veel eenvoudiger dan het hacken van techniek.

[Larry4]

Inderdaad, ook is sms makkelijk uit de lucht te sniffen met bijv. een RTL-SDR dan zou iemand in de buurt net iets eerder (ge-automatiseert) een sessie kunnen opzetten waardoor je eigen sessie niet meer werkt.

[Yuran]

Ik ben fan van 2FA, want bij de meeste websites is de implementatie snel en simpel. Ik hoef het niet continu opnieuw in te voeren, wat ook veel tijd scheelt.

Echter ben ik absoluut geen fan van bedrijven die dan hun eigen 2FA gaan zitten maken. Half gebakken, zodat ze het kunnen gebruiken als verkooppraatje. Denk hierbij bijvoorbeeld aan battle.net/blizzard, zodra je telefoon crasht en je hem reset, mag je lekker je ID gaan opsturen ter verificatie. Anders herstellen zij hem gewoon niet, al kan je elke factuur dat je ooit hebt betaald laten zien.

Dit voelt in mijn geval dan niet zo veilig meer, maar ik zou ook graag willen weten hoe anderen dat ervaren.

[R4gnax]

mag je lekker je ID gaan opsturen ter verificatie

Mogen ze hier in Nederland niet eens om vragen. Zijn maar een paar instanties die je ID wettelijk mogen verwerken.
Helaas heb je tegenwoordig een contract voor dienstverlening met Blizzard in de UK en zijn ze uit de EU vertrokken; dus je kunt er nu nog minder tegen beginnen dan je een paar jaar geleden al kon.

[NullCrayfish]

En dan baal je dat je je ooit met een pseudoniem geregistreerd hebt

[Yuran]

Nou, ik heb dus geen flauw idee en zit nog te twijfelen om het te doen hahaha.

[Yggdrasil]

Mee eens. Ik erger me bijv. aan Medium.com die geen wachtwoord meer gebruiken maar ze sturen een mail met een tijdelijke inloglink. Ontzettend irritant omdat ik dan bijv. eerst mijn privé mail moet gaan openen op een werk PC.

Of Sendgrid.com die alleen Authy toestaat als TOTP generator omdat die beiden eigendom zijn van Twilio. In plaats van standaard TOTP codes die ik in elke app kan instellen moeten ik en mijn collega's dus specifiek voor hen nog een aparte app installeren.