2FA : GitHub déroule son plan sans éviter les concessions

La vérification d’identité par SMS, un risque nécessaire ?

Cette flexibilité est potentiellement risquée, selon certains utilisateurs, mais elle est compréhensible, car GitHub cherche à faire entrer des millions de développeurs dans le monde dans le système 2FA. Les SMS sont désormais considérés comme moins sûrs que les autres méthodes de validation, comme l’a reconnu Github, dans un billet de blog publié la semaine dernière. Le NIST considère cette méthode d’authentification comme obsolète depuis 2016. Les attaquants ont des moyens d’intercepter ces messages en utilisant des techniques telles que l’échange de cartes SIM.

« Il y a encore des régions du monde où le déploiement des jetons matériels et autres n’est tout simplement pas réalisable, ou peut-être qu’ils n’ont pas de [smartphones] », évoque Reed Loden, vice-président de la sécurité chez Teleport, un fournisseur d’accès sécurisé. « GitHub essaie d’être le centre de développement pour le monde entier… il peut donc être nécessaire de soutenir cette étape provisoire, bien que j’aimerais voir le SMS complètement disparaître à l’avenir, simplement parce qu’il n’est pas sûr [en tant que facteur d’authentification] ».

Un autre utilisateur de GitHub a comparé la prise en charge des SMS à la position de Twitter, que le réseau social a supprimé le 15 février pour les utilisateurs non payants.

« Ce que Twitter a fait en désactivant le 2FA par SMS à moins que vous ne payiez une prime n’est pas la bonne solution », avance Rick Rackow, SRE senior chez Tomtom. « Pointer du doigt les problèmes tout en laissant la décision à l’usager est nettement mieux, c’est pourquoi j’aime l’approche de GitHub ».

Une mise à jour du blog officiel de GitHub en décembre comprenait également des informations sur une vérification prévue pour les utilisateurs de GitHub.com 28 jours après l’activation de l’authentification double facteur. Cette vérification permettra aux utilisateurs de reconfigurer le 2FA s’ils ont égaré leur deuxième facteur ou s’ils ont besoin de réinitialiser leur mot de passe.

La période de contrôle de 28 jours introduit également un certain risque, signale Rick Rackow.

« Fondamentalement, cela signifie que toute personne souhaitant prendre le contrôle d’un compte sait qu’il s’agit de sa dernière chance », déclare-t-il. « Cependant, il est très probable que tout se passera bien. D’une manière générale, il s’agit d’un grand pas en avant vers une chaîne d’approvisionnement plus sûre pour tous ceux qui utilisent des logiciels libres et ouverts ».

GitHub établit un calendrier 2FA et teste les clés FIDO

En novembre, GitHub a commencé à exiger le 2FA pour les mainteneurs de paquets npm ayant plus d’un million de téléchargements hebdomadaires ou plus de 500 dépendances. Le déploiement du 2FA sur GitHub ce mois-ci donnera la priorité aux groupes qui s’inscrivent rapidement et qui sont considérés comme critiques, d’après le message de décembre. GitHub ne précise pas exactement quels développeurs font partie de ces groupes, mais indique que cette sélection s’appuiera sur des critères incluant les administrateurs d’entreprises et d’organisations, ainsi que les contributeurs aux 4 millions de dépôts publics et privés les plus importants.

Les utilisateurs préinscrits commenceront à recevoir des rappels réguliers dans le produit et des rappels occasionnels par e-mail pour activer le 2FA pendant 45 jours avant la date limite de leur groupe d’inscription, débutant ce lundi. Une fois la date limite d’inscription au 2FA atteinte, les utilisateurs pourront retarder cette notification jusqu’à sept jours avant de se voir bloquer l’accès aux fonctionnalités de GitHub jusqu’à ce que le 2FA soit activé.

« Ne vous inquiétez pas », tempèrent les porte-parole de GitHub dans leur billet de blog. « Cette période de suspension ne commence qu’une fois que vous vous êtes connecté après la date limite, donc si vous êtes en vacances ou absent du bureau, vous aurez toujours cette période d’une semaine pour configurer l’authentification lorsque vous serez de retour à votre bureau ».

Alors que certains utilisateurs de GitHub se sont opposés à l’exigence du 2FA, estimant qu’il s’agissait d’une entrave inutile à la productivité des développeurs dans les dépôts de code moins sensibles, d’autres estiment qu’il s’agit d’une idée qu’il est temps de mettre en œuvre.

« Pour un produit comme GitHub, on peut supposer que les utilisateurs sont suffisamment avertis sur le plan technique pour comprendre comment utiliser le 2FA, et c’est un moyen relativement facile de renforcer considérablement la sécurité des usagers », poursuit Rick Rackow.

GitHub a également réaffirmé la semaine dernière qu’il testait les passkeys du consortium industriel FIDO Alliance, qui développe des « normes ouvertes, plus sûres que les mots de passe et les OTP par SMS, plus simples à utiliser pour les consommateurs et plus simples à déployer et à gérer pour les fournisseurs de services ». Les passkeys utilisent des normes de chiffrement à clé publique pour authentifier les appareils clients protégés par des données biométriques, tels que les smartphones, ce qui élimine complètement l’authentification par mot de passe.

Les experts du secteur considèrent les passkeys comme le moyen idéal à long terme pour contrecarrer les attaques de la chaîne d’approvisionnement logicielle sur la plateforme.

« Les passkeys élimineront les problèmes de productivité des développeurs et représentent l’avenir de l’authentification », prédit Larry Carvalho, analyste indépendant chez RobustCloud.

Entre-temps, il y a eu de nombreux exemples d’exploitation des environnements de développement pour accéder à des secrets d’entreprise, rappelle l’analyste.

« Les développeurs sont soumis à un stress pour être productifs et sont des cibles prometteuses pour les pirates exploitant l’ingénierie sociale », indique Larry Carvalho. « Tout changement qui réduit la productivité des développeurs suscitera des réactions négatives, mais j’applaudis GitHub pour avoir mis en œuvre cette mesure essentielle ».