GitHub n'accepte plus les mots de passe de compte pour l'authentification des opérations Git
et propose aux développeurs une authentification basée sur des jetons
En juillet 2020, GitHub a annoncé son intention d'exiger l'utilisation d'une authentification basée sur des jetons (par exemple, un accès personnel, un jeton d'installation OAuth ou GitHub App) pour toutes les opérations Git authentifiées. L'équipe avait expliqué :
« Ces dernières années, les clients de GitHub ont bénéficié d'un certain nombre d'améliorations de la sécurité de GitHub.com, telles que l'authentification à deux facteurs, les alertes de connexion, les appareils vérifiés, la prévention de l'utilisation de mots de passe compromis et la prise en charge de WebAuthn. Ces fonctionnalités rendent plus difficile pour un attaquant de prendre un mot de passe qui a été réutilisé sur plusieurs sites Web et de l'utiliser pour essayer d'accéder à votre compte GitHub. Malgré ces améliorations, pour des raisons historiques, les clients sans authentification à deux facteurs activée ont pu continuer à authentifier les opérations Git et API en utilisant uniquement leur nom d'utilisateur et leur mot de passe GitHub ».
Aussi, depuis le 13 novembre 2020, GitHub n'accepte plus les mots de passe de compte lors de l'authentification avec l'API REST et exige l'utilisation d'une authentification basée sur des jetons, comme un jeton d'accès personnel (pour les développeurs) ou un jeton d'installation OAuth ou GitHub App (pour les intégrateurs) pour toutes les opérations d'API authentifiées sur GitHub.com.
Selon elle, l'utilisation de jetons offre un certain nombre d'avantages de sécurité par rapport à l'authentification par mot de passe :
- Unique : les jetons sont spécifiques à GitHub et peuvent être générés par utilisation ou par appareil
- Révocable : les jetons peuvent être révoqués individuellement à tout moment sans avoir besoin de mettre à jour les informations d'identification non affectées
- Limité : les jetons peuvent être limités pour autoriser uniquement l'accès nécessaire au cas d'utilisation
- Aléatoire : les jetons ne sont pas soumis aux types de tentatives d'attaque par force brute que les mots de passe plus simples que vous devez retenir ou saisir régulièrement pourraient être
GitHub a également déprécié l'authentification par mot de passe pour l'authentification avec l'API REST depuis le 13 novembre 2020.
Dans le même billet datant de juillet 2020 où la mesure a été annoncée, GitHub a donné la chronologie suivante :
- Aujourd'hui : si vous utilisez des mots de passe pour vous authentifier avec l'API aujourd'hui, vous pouvez recevoir un e-mail vous invitant à mettre à jour votre méthode d'authentification ou votre client tiers.
- 30 septembre et 28 octobre : un accès personnel ou des jetons OAuth seront temporairement requis pour toutes les opérations d'API afin d'encourager les clients à mettre à jour leur méthode d'authentification.
- 13 novembre : un accès personnel ou des jetons OAuth seront requis pour toutes les opérations authentifiées avec l'API REST (un jeton d'accès personnel est déjà requis pour l'authentification avec l'API GraphQL).
- Mi-2021 : un accès personnel ou des jetons OAuth seront requis pour toutes les opérations Git authentifiées.
Rendu en 2021, GitHub déclare que, depuis le 13 août 2021, il n'accepte plus les mots de passe de compte lors de l'authentification des opérations Git sur GitHub.com. Au lieu de cela, une authentification basée sur des jetons (par exemple, accès personnel, OAuth, clef SSH ou jeton d'installation de l'application GitHub) sera requise pour toutes les opérations Git authentifiées.
Voici les éléments affectés :
- Accès Git en ligne de commande
- Applications de bureau utilisant Git (GitHub Desktop n'est pas affecté)
- Toutes les applications/services qui accèdent aux référentiels Git sur GitHub.com directement à l'aide de votre mot de passe
Les clients suivants ne sont pas concernés par ce changement :
- Si vous avez activé l'authentification à deux facteurs pour votre compte, vous devez déjà utiliser l'authentification basée sur des jetons ou SSH.
- Si vous utilisez GitHub Enterprise Server, nous n'avons annoncé aucune modification de notre offre sur site.
- Si vous maintenez une application GitHub, les applications GitHub ne prennent pas en charge l'authentification par mot de passe.
Si vous utilisez toujours un nom d'utilisateur et un mot de passe pour authentifier les opérations Git, vous devez suivre les étapes suivantes pour éviter toute interruption :
- Pour les développeurs, si vous utilisez un mot de passe pour authentifier les opérations Git avec GitHub.com, vous devez commencer à utiliser un jeton d'accès personnel sur HTTPS (recommandé) ou une clef SSH. Si vous recevez un avertissement indiquant que vous utilisez une intégration tierce obsolète, vous devez mettre à jour votre client vers la dernière version.
- Pour les intégrateurs, vous devez authentifier les intégrations à l'aide des flux d'autorisation Web ou d'appareil.
Si vous voulez vous assurer que vous n'utilisez plus l'authentification par mot de passe, vous pouvez activer l'authentification à deux facteurs, qui nécessite OAuth ou des jetons d'accès personnels pour toutes les opérations authentifiées avec Git et des intégrations tierces.
Si vous avez déjà activé l'authentification à deux facteurs pour votre compte GitHub, vous ne serez en aucun cas affecté par ce changement d'authentification puisque vous utilisez déjà une authentification basée sur des jetons ou SSH.
GitHub a amélioré la sécurité des comptes au fil des ans en ajoutant une authentification à deux facteurs, des alertes de connexion, des appareils vérifiés, le blocage de l'utilisation de mots de passe compromis et la prise en charge de WebAuthn.
L'authentification basée sur des jetons pour authentifier les opérations Git augmente la résilience des comptes GitHub contre les tentatives de prise de contrôle en empêchant les attaquants d'utiliser des informations d'identification volées ou des mots de passe réutilisés pour pirater des comptes.
En mai, GitHub a également ajouté la prise en charge de la sécurisation des opérations SSH Git à l'aide des clefs de sécurité FIDO2 pour une protection supplémentaire contre les tentatives de prise de contrôle.
Source : GitHub (1, 2, 3)
Et vous ?
Que pensez-vous de cette décision ?
Partager