Au fil des années, le secteur s’est perdu dans ses tentatives pour augmenter (ou bien mettre à niveau) les mots de passe, en utilisant toutes sortes de terminologies déroutantes telles que l’authentification à deux facteurs (2FA), l’authentification en deux étapes, l’authentification multifacteur (MFA) et plus récemment les nouveaux moyens proposés tels que l’U2F (Universal Second Factor), le Fast IDentity Online 2 (FIDO2), le WebAuthn sans oublier les clés d’accès.
Jusqu’à présent, la plupart d’entre nous étions assez heureux de voir un fournisseur adopter l’un des moyens mentionnés ci-dessus. Tout ce qui va au-delà d’un mot de passe constitue une amélioration, mais nous sommes aujourd’hui arrivés au stade où nous devons relever le niveau minimum en termes d’acceptabilité. Dans cet article, je vais examiner l’état actuel du contournement des méthodes d’authentification “plus fortes” et, je crois, pouvoir vous indiquer la meilleure voie à suivre.
Des solutions vraiment intelligentes ?
Trop d’options “2FA” parmi les plus simples ne correspondent pas à ce que l’authentification à deux facteurs est réellement censée être. Idéalement, les solutions à deux facteurs correspondent à deux des trois types suivants : un élément que vous connaissez (comme un mot de passe ou un code PIN), un élément que vous possédez (comme un jeton USB/Bluetooth, une SmartCard ou une paire de clé publique/privée) ou bien un élément qui fait partie de vous (comme une empreinte digitale ou une empreinte faciale). Malheureusement, la plupart des premières solutions se résument à des éléments que vous connaissez ou bien à d’autres informations que vous connaissez également.
Prenez les jetons RSA, les SMS ou les “2FA” de type TOTP (mots de passe à usage unique basés sur le temps ; par exemple, Google Authenticator ou Authy), où dans la plupart des cas, on vous présente un code à 6 chiffres qui change toutes les 30 secondes. Bien que les gens aient critiqué les implémentations à base de SMS en raison de la possibilité d’attaque de type SIM Swapping, la réalité est qu’elles sont toutes faibles et susceptibles d’être interceptées.
Voilà le problème. Imaginez que vous receviez un email de phishing bien conçu (peut-être même généré par l’IA !). Pour que l’escroc réussisse à vous compromettre à ce stade, vous devez croire que l’email est légitime, et ce, que vous utilisiez ou non l’authentification multifacteur. C’est à ce moment-là que le fait de solliciter une personne via deux éléments différents qu’il connaît (son mot de passe et un code secret généré dynamiquement) se termine en drame : Si vous pensez vraiment que vous vous connectez à votre compte bancaire, à votre compte de messagerie ou à votre compte d’entreprise, vous divulguerez alors volontiers non seulement votre mot de passe, mais également le code secret. Ce type d’authentification ne fonctionne que dans un seul sens : l’escroc vérifie votre identité, mais vous n’avez pas vérifié l’identité de l’entité qui vous demande la preuve en retour.
Il existe en effet des outils disponibles gratuitement pour automatiser cette tromperie. L’un des plus populaires s’appelle evilginx2. Initialement basé sur le serveur Web populaire nginx, il s’agit désormais d’une application Go autonome qui sert d’outil tout-en-un pour pirater l’authentification multifacteur basée sur les connaissances (knowledge-based) et voler les cookies de session pour contourner l’authentification. Cette possibilité a permis d’abaisser la barrière à l’entrée pour lancer des attaques malveillantes.
Comment en sommes-nous arrivés là ?
Si l’on considère l’histoire de la compromission des identifiants, tout a commencé par l’analyse de réseaux Wi-Fi non chiffrés ou par le lancement d’attaques basées sur le réseau avant que le chiffrement ne soit introduit. En 2010, il existait un outil tristement célèbre appelé FireSheep, conçu pour permettre aux attaquants de visiter un café et de voler passivement les identifiants de connexion des utilisateurs à cause du manque de chiffrement sur le Web.
En réponse à ces attaques et aux fuites d’informations d’Edward Snowden en 2013, nous avons décidé de chiffrer presque tout ce qui se trouvait en ligne. Ce changement nous a protégés contre ce que l’on appelle les attaques de type MitM (Machine-in-the-Middle). Nous avons désormais une utilisation quasi omniprésente du protocole HTTPS sur le Web et même dans nos applications pour smartphone, empêchant ainsi à un passant lambda de capturer tout ce que vous pourriez voir ou faire en ligne.
Les cybercriminels sont ensuite passés au vol d’identifiants, et dans une large mesure, la plupart d’entre nous sommes passés à un autre type d’authentification multifacteur, mais encore une fois, généralement il s’agit de la variante la moins chère et la plus simple : à savoir un élément que nous connaissons, plus un autre élément éphémère que nous connaissons aussi. Il s’agit d’un ralentisseur inefficace, et nous devons à nouveau passer à autre chose.
Après de nombreuses réunions de comité et la création d’organismes de normalisation, le consensus du secteur s’est arrêté sur une norme largement acceptée connue sous le nom de Web Authentication APIeb, ou WebAuthn. Si vous souhaitez approfondir les différents éléments mentionnés ci-dessus, il existe un thread Reddit pour vous guider, mais je n’entrerai pas trop dans les détails ici.
À la découverte de WebAuthn
WebAuthn/passkeys rend l’authentification multifacteur capable de résister au phishing. Rien n’est parfait, bien sûr, et des recherches récentes ont découvert un vecteur d’attaque MitM “limité mais intéressant” impliquant des périphériques matériels spécialisés et une CVE corrigée depuis. D’ailleurs à partir de maintenant, nous l’appelons authentification multifacteur résistante au phishing (phishing-resistant multifactor authentication).
Examinons le processus. Je souhaite créer un compte sur un réseau social populaire. En utilisant mon smartphone ou mon ordinateur avec une prise en charge de la clé d’accès, je choisis de créer un nouveau compte avec cette dernière. Le site me demande le nom d’utilisateur souhaité (généralement mon adresse email). Mon appareil envoie le nom d’utilisateur au site, et il répond avec mon nom d’utilisateur, une vérification et le nom de domaine du site. Mon appareil génère une paire de clés cryptographiques unique, la stocke en toute sécurité avec le nom du site et le nom d’utilisateur, passe la vérification du site et attache la clé publique associée pour que le site l’utilise désormais comme identifiant.
La prochaine fois que j’irai sur ce site, je n’aurai plus besoin et je n’utiliserai plus de mot de passe, qui, selon cette définition, n’est qu’un secret partagé qui pourrait être volé ou bien réutilisé. Au lieu de cela, comme le montre la figure 1, j’envoie le nom d’utilisateur qui correspond au nom de domaine de ce site. Le site répond par une vérification. Mon appareil recherche la clé de ce nom de domaine et l’utilise pour passer la vérification, prouvant ainsi mon identité.
Figure 1 : Le flux de type ‘expérience utilisateur’ de l’autorisation WebAuthn est fluide, la plupart des actions se déroulant entre le fournisseur d’identifiant de l’utilisateur, le navigateur et le site.
Pour obtenir plus d’informations, vertx.io propose un approfondissement centré sur le développeur dans les mécanismes du processus.
Qu’est-ce qui pourrait mal se passer ?
Avec cette combinaison de points de données, la clé ne peut pas être facilement volée ou réutilisée, et je ne peux pas être amené à essayer de me connecter à un site frauduleux avec un nom de domaine similaire (mais ici aussi il y a une petite surface d’attaque : si vous ajoutez une clé d’accès pour zuzax.com et que je peux créer un sous-domaine sous mon contrôle en tant qu’attaquant, phish.zuzax.com, je peux vous faire passer une vérification après relance).
Au-delà de mon appareil, l’endroit où sont stockées les clés détermine leur sécurité contre le vol et les abus. L’utilisation de jetons U2F matériels, comme une YubiKey ou une SmartCard, garantit que les clés soient verrouillées sur cet appareil et ne puissent pas être extraites, faisant du vol physique la seule option concrète. Certains jetons matériels nécessitent également une biométrie, un code PIN ou une passphrase pour être déverrouillés. Avec l’avènement des clés d’accès, les clés secrètes peuvent être synchronisées sur le Cloud de votre fournisseur de système d’exploitation (iCloud, Google Drive, OneDrive) ou via votre gestionnaire de mots de passe (Bitwarden, 1password, etc.), les rendant ainsi plus vulnérables au vol si votre compte devait être compromis.
Et bien sûr, il faut que cela soit mis en œuvre. Ce déploiement doit être réalisé par les sites (où nous avons fait des progrès relativement rapides à ce sujet au cours des dernières années) et, comme toujours, par les entreprises qui doivent l’activer et l’utiliser dans leurs environnements spécifiques. Cela n’est pas si différent de nos conseils récurrents aux professionnels de la sécurité qui rappellent de considérer l’authentification multifacteur comme une hygiène de base (avec les correctifs et la désactivation des RDP inutiles), mais cela doit toujours être véritablement budgétisé et mis en œuvre.
La dernière faiblesse restante est le cookie de session qui est défini lors de la connexion, mais c’est un sujet pour un autre article.
Cela va dans les deux sens (et nous fait avancer)
En tant qu’utilisateur, je devrais pouvoir prouver mon identité à mon appareil en utilisant un code PIN, une empreinte digitale ou une empreinte faciale, et laisser l’appareil effectuer le travail d’authentification des deux parties. C’est la partie la plus importante de cette transaction : sa bidirectionnalité.
Nous savons tous que le vol de mots de passe est un problème, et nous n’avons fait que prolonger leur durée de vie en essayant de les compléter avec d’autres types d’authentification basée sur les connaissances (knowledge-based). Les informations peuvent être et seront volées, interceptées et réutilisées. Si nous voulons vraiment avoir une authentification multifacteur, nous devons aller au-delà des seuls éléments connus et exiger des preuves plus solides.
Il s’agit d’une opportunité de dépasser le stade où la sécurité est une source de friction pour les utilisateurs ; en fait, elle améliore activement la sécurité tout en diminuant les contraintes. Les implémentations de clés d’accès actuelles peuvent être capricieuses et maladroites, mais je suis convaincu que ceux qui les adopteront en bénéficieront le plus et que nous résoudrons rapidement les problèmes d’interface utilisateur. Nous n’avons pas le choix. C’est la meilleure solution à notre disposition et les cybercriminels n’attendront pas que nous en soyons convaincus pour en comprendre tous les mérites.
Billet inspiré de The future of MFA is clear – but is it here yet?, sur le Blog Sophos.
