GitHub annonce sur son blog qu'il exigera désormais de ses utilisateurs qu'ils « activent une ou plusieurs formes d'authentification à deux facteurs (2FA) d'ici la fin de 2023 ».
« La sécurité logicielle commence par le développeur », explique la plateforme, qui évoque également la « chaîne d'approvisionnement du logiciel », maillon faible de plus en plus exploitée par les APT :
« Les comptes de développeur sont des cibles fréquentes d'ingénierie sociale et de prise de contrôle de compte, et la protection des développeurs contre ces types d'attaques est la première et la plus importante étape vers la sécurisation de la chaîne d'approvisionnement. »
GitHub avait déjà, en février dernier, exigé des principaux mainteneurs de packages npm qu'ils optent pour la 2FA, mais son adoption reste encore très faible : « Aujourd'hui, seulement environ 16,5 % des utilisateurs actifs de GitHub et 6,44 % des utilisateurs de npm utilisent une ou plusieurs formes de 2FA. »
GitHub renvoie dès lors à sa documentation sur la 2FA, et rappelle qu'il convient également, non seulement de sauvegarder ses codes de récupération, mais également de configurer une ou plusieurs méthodes de récupération de compte.
Commentaires (27)
#1
Et bien sûr, ils mettent tout le monde dans le même panier en considérant que tous font du soft professionnellement avec des risques de sécurité importants. Peut-être aussi que s’il y a peu d’adoption de la 2FA, c’est que pas mal d’utilisateurs sont juste des amateurs qui partagent quelques bouts de code qu’ils ont fait pour eux-même, pour qu’ils puissent servir à quelqu’un à l’occasion, ou même simplement de serveur Git déjà fonctionnel et hébergé à l’extérieur.
Je déteste ce genre de décision qui définit à ta place ce qui est bien pour toi, et sans aucune nuance.
#2
Justement, un partie de l’écosystème opensource est basé sur des bouts de codes balancé sur le web sans grande conviction et jamais maintenus (NPM, oui toi là-bas, ne te cache pas). C’est triste, mais c’est la réalité. Vouloir sécuriser un peu tout ça ne me semble pas déconnant.
De toute façon lorsque le 2FA n’était pas obligatoire, on raillait déjà GitHub sur son manque de professionnalisme : quoi, pas de 2FA obligatoire ? Scandaleux !
Le 2FA désormais (bientôt) obligatoire : quoi ? Dictature !
Bref, on ne peut contenter tout le monde, et quitte à choisir entre une sécurité variable, et une sécurité supérieure pour tout le monde, le choix le semble vite fait. Et puis bon, si tu ne veux (ou ne peux) pas partager ton bout de code sur GitHub, tu es libre d’aller le faire sur une autre plateforme :)
#3
Finalement, les seuls utilisateurs que ça va légitimement agacer, ce sont ceux qui s’inscrivent pour remonter des bugs. Là, ouaip, c’est relou pour eux. Déjà que s’inscrire est un effort louable, mais en plus devoir donner davantage d’infos (tél ou app ou email j’imagine ?) juste pour ça, humpf…
Une piste de solution serait d’avoir un compte github limité, avec option “développeur”.
#3.1
Après si tu as un compte, tu as filé une adresse mail.
Du coup pourquoi ne pas aussi activer la 2FA dessus ?
#4
Ha mais tout à fait :)
Juste, on peut trouver ça agaçant lorsqu’on utilise des outils qui ne prennent pas en change le 2FA, ou lorsque son intégration n’est pas top.
Ou juste c’est chiant ^^. Par exemple tu enregistres ton accès github dans IntelliJ, et tu le fais avec 2FA. Ok, seulement tu as fais ça sur ton IDE du boulot, et tu n’a peut être pas ton compte email sous la main. Donc le jour où tu dois t’authentifier à nouveau, il faut sortir l’accès mail (qui sera par ex sur le smartphone). Ce n’est pas insurmontable, mais à force c’est lourd…
#4.1
Oui, je te comprends.
À un moment vaut mieux laisser le choix, ça évite généralement certains problèmes
Après la pédagogie, aux gens de se prendre un minimum en main.
J’imagine que Github a envoyé des mails de préventions, des choses comme ça non ?
Du coup c’est vrai que faire du forcing sur tout le monde, c’est pas forcément une bonne solution.
Après, je ne connais pas ce dossier plus que ça.
#5
Les modifications de code ne passent pas inaperçues sur Git, on peut difficilement faire plus transparent. Et utiliser des bouts de code de gens random sans vérifier et avec mise à jour automatique, c’est quand-même risqué, ne serait-ce qu’en terme de fiabilité fonctionnelle.
J’ai jamais compris ce que ça pouvait bien leur faire à ceux-là, on leur interdit pas d’utiliser le 2FA pour eux. Pour le cas spécifique de GitHub, on leur met un voyant sur chaque dépôt qui est sous 2FA et voilà, ils savent où piocher leur code de “confiance”.
#6
Hélas, l’opensource nous apprend que ça a beau être ouvert, les gens regardent le code une fois que le mal est fait. Mettre à jour ses dépendances sans vérifier, dont la petite lib proposée par DarkCodeur666, c’est idiot quand on y pense, mais dans les faits, qui vérifie ? Pas grand monde.
Qui a vérifié les commits, et surtout quand ? 
Bah voilà.
On se rappellera de ces devs de libs JS (de toute taille et toute popularité) qui ont récemment protesté contre plein de choses (manque de reconnaissance, prise de position face à la guerre en Ukraine…) en affichant de la pub ou en vidant le disque dur
Mais c’est tellement ça ^^, 200% d’accord.
#7
C’est insupportable ce genre de pratiques ! Une véritable prise d’otage
#7.1
Ce n’est pas une prise d’otage, au contraire, tu peux partir si cela ne te convient pas.
#7.2
C’est quoi le souci, on te demande pas de te couper un membre, mais d’activer le 2FA qu’un IT devrait automatiquement faire sans qu’on lui demande… qu’il soit pro ou amateur.
#7.4
Le 2FA ne sécurise rien du tout, c’est juste un moyen détourné pour récupérer des numéros de téléphone.
Franchement qu’est qui empêche de se connecter en 2FA pour poster un malware dans une libraire github ? C’est exactement le même niveau de sécurité avec ou sans. L’argumentaire est totalement farfelu !
#7.3
“Oh mon dieu, on me force à sécuriser mon compte, sachant que mon travail peut être une dépendance du travail d’autres personnes. Laissez-moi le droit de compromettre toute une chaîne d’approvisionnement si je le veux !”
Bon, l’histoire n’étant qu’un éternel recommencement, c’est le même genre de débat qu’il y a 50 ans avec la ceinture de sécurité : https://www.ouest-france.fr/economie/automobile/dangereuse-ridicule-genante-quand-la-ceinture-de-securite-faisait-debat-b8236d6e-ef98-11eb-8f8e-fe71c11b7838
#8
Avis bien péremptoire et totalement dénué de nuance, contexte et argumentation.
Ceux qui partagent leur code n’ont aucun devoir envers ceux qui l’utilisent, et c’est d’ailleurs souvent formalisé dans la licence quand il y en a une. Ils sont déjà bien sympathiques de le faire, ça s’arrête là, il ne faut pas l’oublier. C’est une inversion particulière de l’esprit de l’open source que de penser ce que tu exprimes.
Perso, si je décide de partager du code sur une plateforme sans 2FA, et que d’autres ne veulent pas l’utiliser pour cette raison, grand bien leur fasse, ils font ce qu’ils veulent, et moi aussi.
#9
Certains ici ne doivent pas connaître npm. C’est utilisé entre autre par angular. Une application angular de base, c’est déjà 1200 dépendances. Vous croyez vraiment qu’un développeur va vérifier toutes les mises à jour ?
Non, le 2FA obligatoire c’est vitale. Perso, je l’active toujours dès que c’est possible, même sur des services que je gère moi-même (Nextcloud, cockpit, etc.).
#10
Indépendamment du 2FA, le vrai problème, il est plus ici : 1200 dépendances et ça ne te choques pas ?
#10.1
Que veux-tu, c’est du JavaScript/typescript et c’est développé par Google… Après c’est de plus en plus le cas dans les langages modernes. En .Net 6, on utilise aussi pas mal de dépendances, beaucoup moins tout de même. Mais le principe reste le même : des bibliothèques Nuget libres souvent hébergées sur GitHub.
#11
Qu’est-ce qu’il ne faut pas lire, vraiment. Et le tout dit avec un aplomb à toute épreuve.
3s de recherche sur internet avec “MFA sans téléphone”, et les 3 premiers résultats sont :
Et oui, ces solutions sont supportées : https://docs.github.com/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication#in-this-article
Quand bien même un éditeur aurait ton numéro de téléphone, que va-t-il se passer ? Ils vont t’appeler pour te proposer du CPF ou de l’isolation à 1€ ?
Ton texte est bancal ici, et ça dénote une méconnaissance du principe du MFA.
Soit tu pars du principe que n’importe qui peut se connecter sur un compte, même avec du MFA, et dans ce cas-là, j’aimerais bien savoir comment un attaquant peut se connecter sur un compte qui a une solution de MFA un peu sécurisée (donc qui ne dépend pas de réseau téléphonique).
Soit tu pars que chaque projet disponible sur github est utilisé, peu importe le code dedans. Pas sur que l’use case existe. Par contre, un projet légitime (au choix, le noyau linux ? mais prend l’exemple qui te parles le plus) qui peut se faire compromettre parce qu’un de ses utilisateurs privilégiés s’est juste fait voler son compte, ça, c’est le pourquoi de la décision de GitHub.
Je doute que les contributeurs de plein de projets ne font ça que “bien sympathiquement” et que leur engagement “s’arrête là”. Sinon, pourquoi il y a des process de qualité / vérification dans énormément de projets (et pas forcément que du code, cf Wikipédia) ? Pourquoi tant de conflits de communautés entre des solutions assez similaires ?
Que tu n’aies aucun objectif de résultat en contribuant sur de (FL)OSS, cela ne fait pas de débat; chacun est libre d’utiliser ou non ta création. Par contre, je pense qu’à un moment, quand ta solution est adoptée, tu as l’obligation morale et intellectuelle de faire le minimum pour assurer la sécurité des autres. La preuve en est, plus personne de sérieux n’utilise SourceForge.
Après, personnellement, savoir que je peux me faire usurper mon identité facilement, ça ne m’enchante pas. Savoir qu’en prime ça peut avoir un impact sur d’autres, c’est le meilleur moyen pour passer quelques années en procédure pour réparer ça.
#11.1
Sauf que github est déjà largement sécurisé, notamment via l’accès SSH.
Les pb de malware sont rarement des hacks de compte, mais simplement des push légitimes qui n’ont pas été revu correctement (ou qui chargeait en dynamique la charge extérieure, le MFA n’apportera absolument rien ici au contraire ça fait croire en une pseudo sécurité totalement inexistante.
Les autres solutions “clé fido” sont inutilisables. Je ne vais pas me promener avec une clé USB dans ma poche ! Le 2FA est une plaie faite par des gens qui n’utilisent jamais leur propre outil. Les devs normaux ont plusieurs PC, regardent un truc sur leur tel portable quand ils n’ont pas un PC sous la main, voir se co directement depuis un PC client. Tout ça est quasi-mission impossible avec cette daube de 2FA : à chaque changement de device ça déconnecte les autres sessions, te demande mot de passe, envoi un SMS que tu ne reçois jamais, c’est quoi la suite ? scanner un extrait d’acte de naissance et envoyer un échantillon d’urine ?
Le pire c’est qu’il y’a souvent un captcha en plus, bah oui quoi de plus louche que d’accéder depuis plusieurs réseaux (mobile, client, fibre perso) avec différents devices (windows client, linux perso…)
#12
Super, pour rentrer dans mon garage j’ai une porte blindée en frontal et derrière un truc qui tient par une ficelle.
Qui plus est, tu ne te connectes pas sur la gestion de ton compte Github en SSH. Donc scénario d’attaque plausible, un attaquant récupère tes supers identifiants sécurisés parce qu’il n’y a que toi qui les connais, se connecte, et supprime ou duplique tes accès SSH suivant le but de son attaque.
Source ?
La très grande majorité des attaques actuelles ne se font pas sur des 0day mais sur des vols d’identités (parce que c’est plus facile, scalable et prédictible qu’une 0day). Pour GitHub c’est pareil, c’est bien plus facile d’aller récupérer le mot de passe de Jean-michel 55 ans qui se croit en sécurité avec son mot de passe custom que d’aller casser le site.
Même pour l’attaque Orion/SolarWinds ( https://en.wikipedia.org/wiki/2020_United_States_federal_government_data_breach ) on parle de comptes compromis qui ont permis ensuite de modifier le code du logiciel …
Pourquoi pas ? Tu as bien ton badge d’entreprise toujours sur toi.
Pour bosser réellement dans la cybersécurité et dans la réponse à incident, c’est une connerie monstre que de dire ça. Dans la même lignée que de dire que le MFA est fait pour t’extorquer ton numéro de téléphone.
Le MFA est fait pour obliger les gens qui ne se remettent jamais en question et qui restent sur des paradigmes d’il y a 30 ans à devoir avoir une hygiène de sécurité minimale.
Si ça t’impacte autant, pose-toi les bonnes questions.
3 PC au quotidien, sans compter les instances dans le cloud, et mon téléphone pro. Et, aucun problème. Je dois avoir à tout casser 4 ou 5 demandes dans la journée, quand j’accède à des données critiques la plupart du temps, ce qui doit me faire perdre environ 2min par jour.
La vraie question c’est, est-ce qu’un dev, qui fait partie des identités privilégiées et donc critique pour les assets de l’entreprise, doit pouvoir se connecter avec tout et n’importe quoi comme il l’entend ? Personnellement, je ne pense pas.
Je serais curieux de connaître le produit et la configuration dans ton contexte. Perso je suis sur du full Azure AD P2, je ne tape jamais mon mot de passe. Dans le pire des cas, j’ai 2 chiffres à écrire dans un popup sur mon téléphone.
Ensuite, le SMS est déprécié depuis des années, on ne devrait utiliser cette option que dans de rares cas.
Encore une fois, je serais très curieux de connaître la solution utilisée.
Le coup du captcha me fait plus penser à une analyse réseau/anti-DDOS pour quelqu’un qui sort d’un VPN ou d’un gros réseau d’entreprise.
#13
Il est bien connu que Microsoft et compagnie ne revendent jamais leurs fiches client, évidemment. Ils prodiguent souvent des services gratuits, à un moment il faut bien que ça soit payé, non ?
Il y a quelques années, Microsoft montrait une telle insistance à vouloir obtenir mon numéro de téléphone que j’ai dû ouvrir jusqu’à 6 comptes Microsoft pour en avoir un seul opérationnel à la fin, les autres étant bloqués car je refusais de coopérer pour avoir le SMS soit-disant de sécurité. C’est au point où j’ai renoncé à jouer à Minecraft.
Après… Github appartenant à Microsoft et ce dernier forçant la double-authentification jusqu’à Minecraft
pour réduire leurs coûts de maintenance en sécuritépardon, pour une supposé amélioration de la sécurité, il n’est pas étonnant que le premier soit enfin concerné.Oui on a l’obligation morale et intellectuelle de maintenir à nos frais et sans espérer de contreparties financières le code dont on faisait cadeau, cela pour assurer la sécurité des autres.
Ça sent le libright.
Non mon gars, démerdes-toi. Tu utilises le code donc à priori tu sais coder et il y a de grandes chances que tu t’en serves pour faire du cash à l’image de OpenSSL par exemple qui a eu longtemps de gros problèmes pour obtenir des fonds pour être maintenu. J’attends ton patch.
#14
Merci de sourcer les utilisations que MS fait des données clientes récupérées sur le MFA.
C’est fou de lire ce genre de trucs, vraiment. Je dirais même, c’est complètement con.
C’est quoi les fameuses réductions de coûts de maintenance de sécurité à mettre PLUS de systèmes ? Plus de R&D, plus de maintenance, plus de couches systèmes.
Comment tu es censé déterminer sans MFA qu’un utilisateur ne s’est juste pas fait tappé son compte ?
Cf plus haut, ça se plaint quand ça demande un captcha et/ou une validation de connection au nom de la sécurité mais le but secret c’est pour voler des données et réduire les coûts.
ça sent le 68-attardé/boomer mental “je fais que qu’est-ce que je veux, rien à foutre des autres tant qu’on ne me demande pas le plus petit effort possible”. ça explique aussi pourquoi tu te vantes de ta haine de MS, qui refuse de plier face à ce que tu veux leur imposer.
Quant à la fin de ta tirade, ça n’explique rien.
Si le propre des communautés (FL)OSS c’est de pousser du code et “démerdes-toi”, explique-moi le principe des communautés avec des règles de participation et de validation aussi strictes.
#14.1
Le seul moment où le Microsoft Privacy Statement indique qu’il ne vendra pas les informations qu’ils ont recueilli de vous et de tiers, c’est si vous êtes mineur ou un souscrivant à Microsoft Education. C’est omis dans le reste, et à mon sens c’est volontaire.
Après tout, quelqu’un doit bien paier les 5 Go gratuits de Onedrive.
S’il n’y a que les mots de passe pour accéder à un service, leur vol consiste un désastre pour la réputation de l’entreprise. Le 2FA permet de limiter la casse en affirmant aux clients que le service est toujours sûr par ce biais même après le vol des premiers.
Il faudra certes dépenser un peu pour le serveur TOTP/HOTP/similaires, mais on pourra faire moins de révision du code source du site et lacher un peu de lest sur les autres serveurs. Je ne sous-estime pas la capacité des entreprises à considérer la sécurité comme secondaire, ou à trouver un moyen de limiter les frais.
On sentait à quel point les entreprises se sont forcées à contre-coeur à donner de l’argent pour OpenSSL en 2014. S’il n’y avait pas eu Heartbleed, elles n’auraient rien donné.
C’est la réalité : moins c’est cher, plus on en demande. Ça pompe le code, ça exige que ça soit entretenu en justifiant d’une « obligation morale » blablabla, alors que le codeur originel préfère consacrer son temps à des activités qui lui permettent de… manger. Ou il est simplement passé à autre chose.
Je me demande qui fait le moins d’efforts ici du coup.
Enfin… Je vois bien des gens pleurer parce qu’un mod d’un jeu n’est plus à jour alors que le code source est disponible et la licence permissive. Je suis d’accord, ce n’est pas simple, j’ai essayé, mais c’est faisable.
#15
ah ok je comprends mieux…
Voilà donc exactement mon propos, les gens qui mettent en place ce type de “solution” ne sont pas ceux qui les utilisent, pour eux ça marche dans leur cas particulier donc c’est supposé marcher pour tout le monde. Les utilisateurs, ce sont souvent des sous-traitants qui se tapent 15 tokens différents, qui sont réclamées en permanences.
J’ai 4 tokens logiciels sur mon téléphone pro, et une 10aines de config VPN, dont la cochonnerie de Microsoft Authentificator qui s’ouvre à quasiment chaque clic. Celui-là c’est le pire, tu ne peux même plus ouvrir un document word, et comme ça marche parfaitement sur les PC de la DSI ses incompétents ne voient pas de pb…
La sécurité informatique ne doit jamais être une contrainte pour les utilisateurs.
#15.1
Bah bien sur, tout le monde est incompétent sauf toi, c’est bien connu.
Tu n’apportes aucun argument ou aucune expérience si ce n’est “ouin ouin je dois valider ma connexion plusieurs fois par jour, c’est une prise d’otage”.
La sécurité, au sens large, est une des responsabilités de l’employeur et de l’entreprise, et il est donc à ce titre normal, sinon obligatoire, qu’ils imposent des mesures. Et, ils font ça aussi pour ton bien; le jour où une attaque va réussir correctement, tu seras au chômage technique quelques semaines dans le meilleur des cas.
Si tu es autant impacté par les mesures de sécurité, c’est que tu es la persona qu’ont en horreur toutes les équipes IT : MrJeSaisTout, “moi en 1822 avant JC je bossais pas comme ça et ça marchait très bien”, “non mais je ne vais pas changer ma façon de bosser parce qu’on a des nouveaux outils/process, je vais forcer pour rester sur l’ancien mode”, “de toute façon vous connaissez pas mon job donc je fais ce que je veux”
Et vu que tu dois faire au quotidien des choses totalement orthogonales avec ce qui t’es demandé d’un point de vue sécurité “parce que moi on me dit pas quoi faire”, bah tu actives autant les systèmes de sécurité.
Tu le disais sur un autre thread, former les gens c’est bien. Je te rejoins là dessus, c’est hyper important. Si tu es éligible aux formations de l’ANSSI (qui j’espère pour toi ne sont pas eux aussi des incompétents), ils délivrent un workshop en 1j sur la réalité de la cybersécurité, dont notamment une partie importante sur les obligations juridiques.
#15.2
Tu as raison garde tes œillères je suis le pb !
#16
Car c’est factuel. En 2022 si il faut argumenter pour activer du 2FA c’est une perte de temps, change de métier.