GitHub n'accepte plus les mots de passe de compte pour l'authentification des opérations Git

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

Pièce jointe 603360

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 :

1. 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.
2. 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 ?

:fleche: Que pensez-vous de cette décision ?

Je suis à 100% pour la suppression des mots de passes manuels. C'est AMHA l'une des pires erreurs de l'histoire de l'informatique (comme pouvait l'être le type null sans prise en charge par les systèmes de types)

GitHub n'accepte plus les mots de passe pour l'authentification Git, les clefs SSH, OAut, jeton d'installation de GitHub App, ou une clef de sécurité matérielle, telle que YubiKey sont désormais exigées

GitHub a toujours été partisan d'une sécurité renforcée pour ses clients et ses communautés de développeurs. De sa prise en charge la plus récente de l'utilisation des clefs de sécurité U2F et FIDO2 pour SSH, à l'annonce en 2019 de la prise en charge de l'authentification Web (WebAuthn) pour les clefs de sécurité et de la prise en charge du second facteur universel (U2F) en 2015, l'entreprise a continué à donner à ses millions de clients la possibilité de protéger leurs comptes et leurs projets grâce à l'utilisation de l'authentification YubiKey basée sur le matériel.

Cependant, GitHub a annoncé qu'à partir du 13 août 2021, il n'acceptera plus les mots de passe des comptes d'authentification Git lors de l'authentification des opérations CLI Git et exigera l'utilisation de références d'authentification plus fortes pour toutes les opérations Git authentifiées sur GitHub.com. Cela inclut les clefs SSH (pour les développeurs), OAuth ou le jeton d'installation de GitHub App (pour les intégrateurs), ou une clef de sécurité matérielle, telle qu'une YubiKey.

Cette annonce s'accompagne également de la poursuite du partenariat entre Yubico et GitHub - ainsi que des YubiKeys en édition limitée à la marque GitHub. Les utilisateurs de GitHub peuvent sécuriser leurs Commits Git en utilisant une clef GPG stockée sur leur YubiKey. C'est un moyen fondamental de s'assurer que les contributions open source sont faites par les bons utilisateurs dans les communautés de développeurs ou les organisations.

Pièce jointe 603562

FIDO2, WebAuthn et l'authentification sans mot de passe connaissent une forte impulsion - plus de la moitié (61 %) des organisations interrogées dans un récent rapport de 451 Research et Yubico ont, soit déployé, soit piloté l'authentification sans mot de passe (34 % des répondants ont déjà déployé la technologie sans mot de passe, 27 % la pilotent). GitHub contribue à la réalisation de cet avenir pour ces organisations en prenant en charge FIDO2 et en s'orientant vers un avenir sans mot de passe pour résoudre les problèmes traditionnels de MFA.

Mais toutes les formes de MFA ne sont pas égales lorsqu'il s'agit de soutenir les organisations dans leur transition vers le sans mot de passe. Les YubiKeys sont conçues pour s'adapter et évoluer avec l'infrastructure de sécurité et peuvent être déployées dans des environnements sans mot de passe (avec les partenaires IAM) sous la forme d'une carte à puce ou d'une clef de sécurité FIDO2, par exemple.

https://www.youtube.com/watch?v=Y3mLBTCiccs

Source : Yubico

Et vous ?

:fleche: Que pensez-vous de cette décision de GitHub ?
:fleche: Que pensez-vous de la sécurisation sans mot de passe ?

Voir aussi :

:fleche: Yubico et Microsoft annoncent la disponibilité générale d'une connexion sans mot de passe pour tous les utilisateurs d'Azure Active Directory (Azure AD), grâce à la Yubikey avec le protocole FIDO2

:fleche: Yubico lance la série YubiKey 5 FIPS, les premières clefs de sécurité multi-protocoles validées FIPS 140-2 du marché permettant une authentification sans mot de passe

:fleche: Microsoft prévoit de mettre fin au mot de passe en 2021 pour s'appuyer sur de nouvelles méthodes d'authentification comme Windows Hello, Microsoft Authenticator et la biométrie