Plus tard ce mois-ci, les personnes qui utilisent GitHub peuvent se retrouver soudainement à recevoir un message d'erreur en essayant de s'authentifier auprès de l'API GitHub ou d'effectuer des actions sur un référentiel GitHub avec un nom d'utilisateur et un mot de passe. La raison en est la suppression de cette option d’authentification par GitHub, avec quelques périodes de «brown-out» impliquant le rejet des mots de passe pour avertir les gens de ce fait.

Ce changement a été initialement annoncé par GitHub en novembre 2019, un calendrier de dépréciation a été attribué en février 2020 et une autre mise à jour du blog en juillet répétant les informations. Comme indiqué ici, seul GitHub Enterprise Server reste inchangé pour le moment. Pour tout le monde, à compter du 13 novembre 2020, afin d'utiliser les services GitHub, l'utilisation d'un jeton OAuth, d'un jeton personnel ou d'une clé SSH est requise.

Bien que cela affectera probablement un bon nombre de personnes qui utilisent l'API REST et les référentiels de GitHub, la question la plus intéressante ici est peut-être de savoir s'il ne s'agit que du début d'une transformation plus large loin des connexions par nom d'utilisateur et mot de passe dans les services.

Aucun ciel ne tombe … pour le moment

Tout d'abord, la bonne nouvelle est que gérer ce changement n'est pas très compliqué, et si la lecture des articles de blog de GitHub vous a rempli de confusion et de différents niveaux de terreur existentielle, voici un moyen simple de le résoudre avec des changements minimes si vous vous avez l'habitude de saisir vos informations d'identification sur la ligne de commande avec le git client:

  1. Basculez vers SSH.

C'est tout. Si vous avez déjà un certificat SSH installé sur votre système, assurez-vous de copier la clé publique dans votre profil GitHub. Après cela, vous pouvez soit cloner à nouveau vos référentiels avec plus de saveur SSH, soit changer l'URL distante git de HTTPS en son équivalent SSH.

Pour ce faire, vous devez ouvrir le .ssh/config fichier dans le dossier racine de votre référentiel local dans votre éditeur de texte préféré (comme Vim) et en modifiant l'URL de la télécommande. Remplacez simplement «https» par «ssh» et ajoutez «git @» avant le nom d’hôte pour que, par exemple, https://github.com/Foo/Bar.git devient ssh://git@github.com/Foo/Bar.git.

Félicitations, vous devriez maintenant pouvoir utiliser votre clé SSH pour pousser, tirer, récupérer, rebaser, squash et toutes ces autres choses vilaines avec vos référentiels distants comme avant. Si vous obtenez des erreurs SSH étranges, il se peut que vous ayez les mauvaises autorisations définies sur votre dossier ~ / .ssh. Sinon, profitez de ne plus taper votre nom d'utilisateur et votre mot de passe (ou votre jeton d'accès) à chaque fois.

Le tableau plus large

Selon GitHub, la raison de ce changement est d'augmenter la sécurité. Au lieu de mots de passe, ils offrent l'utilisation de jetons d'accès personnels (PAT) lors de l'utilisation de l'API REST ou de l'accès aux référentiels git via HTTPS. L'idée est que des PAT peuvent être créés pour des services et des individus spécifiques, afin de limiter et d'accorder certains droits. Le jeton qui en résulte est cependant une longue chaîne que vous n'allez pas simplement vous souvenir et saisir, ce qui rend un gestionnaire de mots de passe indispensable.

Il est révélateur que rien de tout cela ne s'applique à la connexion au site Web GitHub lui-même. Là, vous pouvez toujours utiliser votre nom d'utilisateur et votre mot de passe comme auparavant, éventuellement en plus de l'authentification à deux facteurs (2FA) si vous ne l'utilisiez pas déjà. Ici, le deuxième facteur de 2FA peut être un code envoyé dans un message texte ou une application mobile, ou quelque chose comme WebAuthentication (FIDO2), avec tous les pièges potentiels lors de l'utilisation de la biométrie.

Pour ceux d'entre nous qui utilisaient déjà SSH avec nos requêtes de référentiel GitHub, cela signifie que rien ne change. L'utilisation de jetons d'accès ne devrait pas non plus surprendre quiconque a intégré un système CI ou similaire à GitHub. Cela conduit cependant à se poser la question de savoir quel est l’intérêt du changement de GitHub s’il ne pousse que quelques DevOps à se précipiter pour mettre à jour les services (et corriger les quelques qui tombent). Quelqu'un essaie-t-il vraiment de se débarrasser des mots de passe?

Comme le sait quiconque a déjà géré un grand système multi-utilisateurs dans une université ou une grande entreprise, la gestion des comptes utilisateurs est essentielle. Idéalement, vous voulez garder chaque utilisateur (qu'il s'agisse d'une personne, d'un script shell ou d'un gestionnaire) dans sa propre petite zone d'autorisation. C’est là que l’annonce de GitHub est peut-être la plus déroutante. Comme l'ont noté les commentateurs de Hacker News à propos de l'annonce, il aurait été plus logique d'élargir les jetons d'accès pour créer des rôles plus précis et par projet.

Le pouvoir de la connaissance

Graphique avec l'aimable autorisation de l'EFF.

Le fait que les mots de passe soient réellement problématiques ou non semble dépendre principalement de qui vous demandez. S'il s'agit d'une étude commandée par une entreprise qui vend des alternatives aux connexions par mot de passe, ou par l'entreprise derrière Windows Hello, c'est la chose la plus dangereuse qui soit. Cependant, comme mentionné précédemment, ces alternatives posent des problèmes importants, en particulier la biométrie.

Dans l'authentification des utilisateurs, l'identification peut avoir lieu en utilisant quelque chose que vous avez, quelque chose que vous êtes et quelque chose que vous connaissez. La biométrie consiste à scanner une partie du corps d’une personne et à la comparer avec des données précédemment stockées. Il s'agit de données publiques de plus en plus faciles à copier et à reproduire pour tromper les capteurs biométriques. Et bien sûr, si vos données biométriques tombent entre les mains de mauvais acteurs, vous ne pourrez jamais les changer.

Quelque chose que l'on a (portefeuille, carte de crédit, jeton matériel) est facilement volé ou perdu. C'est pourquoi ces jetons sont inévitablement déverrouillés avec un mot de passe, sous la forme d'un numéro d'identification personnel (PIN), qui est maladroitement dansé comme étant un mot de passe, même si en tant que «quelqu'un sait», c'est totalement un mot de passe.

Les choses que les gens savent sont assez étonnantes, car les seuls moyens de les compromettre sont de les oublier ou de demander à quelqu'un de les enregistrer à l'aide de keyloggers, de guichets automatiques compromis, etc. Ceci est démontré par l'incapacité des départements fédéraux américains à se frayer un chemin iPhones sécurisés par mot de passe. Avec l'utilisation de la reconnaissance faciale, il suffit de tenir le téléphone contre le visage de la personne pour le déverrouiller, ce qui pourrait même être légal pour les empreintes digitales. Dans certains cas, une photographie de la personne suffit.

Tout ce dont vous avez besoin est SSH

Le logo OpenSSH.

De manière réaliste, la bonne chose à propos du changement de GitHub semble être que cela oblige plus de gens à finalement jeter ou réécrire ces anciens scripts et services back-end Java oubliés mais toujours actifs qui contiennent des identifiants de nom d'utilisateur et de mot de passe codés en dur. Leur faire utiliser SSH (éventuellement en utilisant ssh-agent ou GPG) facilite la maintenance et devrait améliorer la sécurité. Même si l'on utilise uniquement des référentiels git à partir de la ligne de commande et que l'on ne se soucie pas d'un gestionnaire de mots de passe, passer à SSH signifie moins de saisie.

En tant que mécanisme d'authentification, SSH fournit une authentification à deux facteurs sous la forme de quelque chose que vous avez (la clé secrète) et quelque chose que vous connaissez (la phrase clé). Ses avantages sont également reconnus par GitLab, qui, depuis le 15 août de cette année, n'offre plus de réinitialisations multifactorielles pour les comptes d'utilisateurs gratuits. Si l'on a une clé SSH enregistrée avec le compte, on peut utiliser l'authentification SSH pour récupérer le compte dans les cas où toutes les autres méthodes d'authentification sont devenues indisponibles.

Ce sont les mots de passe jusqu'au bout

En raison du pouvoir de conserver les informations d'authentification en toute sécurité dans nos cerveaux organiques et squishy, ​​toutes les méthodes d'authentification semblent conduire à une forme de mots de passe à un moment donné. Même les jetons d'authentification «sans mot de passe» nécessitent un mot de passe (PIN), dont il faut se souvenir. Il en va de même pour les cartes de crédit, les cartes de débit, les comptes bancaires en ligne, les cartes SIM, les gestionnaires de mots de passe, etc.

Au dernier décompte, je dois me souvenir des codes PIN pour plusieurs cartes SIM, cartes de débit, cartes de crédit, applications bancaires en ligne et un gestionnaire de mots de passe pour près d'une douzaine au total. Devinez où aboutissent ces codes PIN? C'est correct, dans le gestionnaire de mots de passe, car se souvenir d'une chaîne aléatoire de nombres est délicat, mais se souvenir d'une douzaine d'entre eux est un scénario limite de cauchemar. Était-ce 7634 pour cette seule carte de débit ou 7643? Ou était-ce pour la deuxième carte de crédit? Même le système de hachage cérébral d'Elliot Williams pour les codes PIN lui permet d'écrire la clé publique sur la carte, mais il exige toujours qu'il se souvienne de la clé privée (et comment les hacher dans sa tête).

C’est peut-être là l’attrait de la biométrie: avoir quelque chose qui est juste, sans rien à retenir ou un élément physique à suivre. Pourtant, la biométrie est l'équivalent cryptologique de l'impression de votre clé privée SSH sur votre front (ou du bout des doigts).

En fin de compte, il semble que toutes les routes d'authentification aboutissent à des gestionnaires de mots de passe et à des clés SSH.

LAISSER UN COMMENTAIRE

Rédigez votre commentaire !
Entrez votre nom ici