Caractéristiques d’une authentification forte et présentation des mécanismes d’authentification (première partie)

Ici, nous mettons un pied là où le commercial se mêle de la sécurité, car beaucoup sont persuadés, ou affirment avec force (et étonnamment y compris certains textes législatifs, qui feraient sans doute mieux de se contenter de légiférer sur le quoi, et non sur le comment), qu’une authentification forte est obligatoirement une authentification multi-facteurs (détaillée plus loin). Ceci est inexact : la plupart des mécanismes d’authentification, mono et multi-facteurs, peuvent être forts (c’est-à-dire robustes), et plus important : tous les mécanismes peuvent être faibles, y compris les authentifications multi-facteurs. D’ailleurs l’expression « authentification forte » est devenue un terme en vogue, qui est maintenant employé comme argument essentiellement commercial, et ne caractérise plus réellement un haut niveau de sécurité.

Ce qui caractérise la robustesse, terme plus adapté que « force », d’un système d’authentification, c’est un tout :

• Dès la conception, qui doit savoir adapter les mécanismes aux enjeux et choisir les meilleurs mécanismes (principes privacy & security by design & by default). Par exemple, utiliser un mot de passe, ou un code d’authentification (quelle que soit sa forme), sans en contraindre l’entropie minimale (cf. notre article précédent « Authentification : les mots de passe ont la vie dure, première partie ») est une grave erreur ;

• Et les normes sur lesquelles il repose (notamment des principes cryptographiques), qui doivent avoir été éprouvées par des chercheurs en sécurité, indépendants. Ceci est toujours le cas des normes publiques, moins fréquent avec les « standards » provenant d’éditeurs commerciaux ;

• Et son implémentation (et configuration) : en effet, de nombreuses failles proviennent d’implémentations défaillantes, ou de mauvais paramétrages, même lorsque le mécanisme lui-même est sûr. Cela nécessite des compétences spécifiques, ou à défaut des formations préalables, et de réaliser des audits de sécurité du code source ;

• Et son bon niveau de maintien en condition opérationnelle (disponibilité, correctifs de sécurité, supervision, etc.) ;

• Et l’assurance que toutes les phases du processus (étapes 1 à 4, décrites dans notre article précédent) sont robustes, correctement sécurisées et régulièrement revues, et pas seulement la partie visible de l’iceberg, celle que « voit » le client (l’étape 1 du processus d’authentification).

Exemple : même avec le meilleur mécanisme d’authentification, apportant toutes les garanties de sécurité, si les canaux d’échanges d’informations (étape 2) ou les ressources (étape 4) ne sont pas elles-mêmes suffisamment protégées, la sécurité de l’ensemble du processus ne pourra être raisonnablement qualifié de robuste (principe du « maillon faible »).

L’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) a pertinemment rappelé en 2021 les recommandations relatives à l’authentification multi-facteurs et aux mots de passe (52 pages), dont voici quelques morceaux choisis :

• « En langue française, l’authentification multi-facteur est souvent confondue avec l’appellation authentification forte (ou robuste), ce qui laisserait entendre qu’une authentification multi-facteur est nécessairement plus robuste qu’une authentification avec un unique facteur. Il convient ainsi de différencier authentification multi-facteur et authentification forte. »

• Une authentification forte privilégie « l’utilisation de moyens d’authentification forts reposant sur des mécanismes cryptographiques conformes au RGS (Référentiel Général de Sécurité) ».

• « Ne pas utiliser le SMS comme moyen de réception d’un facteur d’authentification » (recommandation R8), c’est pourtant l’un des systèmes multi-facteurs le plus couramment utilisé de nos jours (absit reverentia vero).

Par ailleurs, on peut se demander pourquoi de nombreux mécanismes d’authentification multi-facteurs imposent (pour le second facteur) un numéro de téléphone mobile pour la double authentification ? Ce qui, en passant, est particulièrement agaçant ! Bien que certains organismes ne peuvent sans doute pas être qualifiés d’amateurs en matière de sécurité, une bonne partie des organismes qui utilisent ce mécanisme ne semblent pas avoir effectué une réflexion de fond préalable, ou n’ont pas consulté leur DPO. Il y a sans doute plusieurs motivations sur lesquelles nous pouvons émettre quelques conjectures :

• Ce second authentifiant est généralement un code envoyé par SMS. Certes le SMS utilise un canal de communication distinct de la première authentification, et la plupart des utilisateurs disposent d’un smartphone. À première vue, cela semble être un bon argument, si l’on exclut le fait que ce canal (SMS) n’est pas sécurisé : non chiffré et très peu de protection sur les smartphones eux-mêmes (par exemple, combien de personnes disposent, sur leur smartphone, d’un pare-feu, d’un antivirus…). Par conséquent, ce second canal n’offre pas de réelle sécurité (cf. ci-dessus).

• De plus, cela néglige ceux, certes peu nombreux, qui n’ont pas de smartphone, pour des raisons économiques ou par choix, ou ceux, bien plus nombreux, qui ont un smartphone, mais qui peut être en panne, oublié, perdu ou volé au moment d’une authentification, ou simplement qui changent de numéro, par choix ou en changeant d’employeur… Comment feront-ils pour s’authentifier dans ces cas-là ? Il existe des mécanismes de secours, mais il ne faut pas que ceux-ci soient moins sûrs que le mécanisme d’authentification nominal, sinon des pirates pourraient l’utiliser ! Pour éviter cela, le mécanisme de secours devrait être plus contraignant, sécurisé, et à usage très ponctuel, donc particulièrement surveillé.

• Dans le cadre professionnel, un principe de base de sécurité est de ne jamais mélanger les usages privés et professionnels. Or tous les collaborateurs n’ont pas de smartphone & numéro professionnel, ils doivent alors utiliser leur smartphone & numéro privé pour les comptes professionnels ! Ce qui est une infraction grave aux principes de sécurité des organismes.

• En tant que donnée personnelle, un numéro de téléphone mobile a plus de valeur et d’intérêt qu’une simple adresse courriel, surtout si le numéro a été vérifié (par exemple, un numéro peut permettre de localiser les personnes, ou les solliciter commercialement, ce qu’une adresse courriel ne permet pas aussi facilement). Ceci peut intéresser particulièrement certains organismes dont le modèle économique repose sur la captation en masse et l’exploitation des données personnelles. Ces organismes font d’ailleurs souvent partie de ceux qui promeuvent avec le plus de ferveur la double-authentification basée sur un numéro de téléphone mobile. On peut légitimement se poser la question des réelles motivations de ces personnes, et au vu de leurs fréquentes fuites d’informations, la « sécurité » parait être plus probablement un prétexte afin de collecter encore plus de données personnelles, et ceci sans justification réelle.

Passons à présent en immersion périscopique, par une revue des principales classes de mécanismes d’authentification unitaires (ou mono-facteur), en essayant d’en extraire les bénéfices, désagréments et risques notables, que ce soit pour le confort des utilisateurs, en matière de SSI et de respect de la vie privée.

Cette liste ne pourra évidemment pas être exhaustive. Toutefois, certaines techniques non détaillées dans cet article ne sont que des variantes ou des combinaisons des principales classes présentées ici (certaines sont mêmes des techniques identiques, mais avec des noms différents).

Par exemple, nous n’aborderons pas les solutions telles que OAuth. En effet, OAuth n’est pas à proprement parler un mécanisme d’authentification, c’est un protocole de délégation d’autorisation, qui intervient après l’authentification elle-même.

Sérieusement ?! Si, si 😉

Certes, c’est historique, mais à une époque, il n’y avait pas de mot de passe dans les (antiques) systèmes informatiques. Puis, même après leur invention (voir plus bas), dans certains milieux, notamment universitaires, certains hackers⁽¹⁾ prônaient de bannir les mots de passe, et certains s’évertuaient même à les supprimer des systèmes qu’ils géraient, pour des raisons plus ou moins fallacieuses (idéologiques notamment).

Pour leur défense, tout ceci se déroulait à une époque où il y avait peu de systèmes informatiques, peu d’utilisateurs, qui étaient presque tous informaticiens, et même la plupart administrateurs des systèmes, il n’y avait pas encore d’Internet, et bien qu’il existait déjà des interconnexions, elles étaient peu répandues. Il y avait peu de données confidentielles, et quasiment aucun pirate. Une autre époque !

⁽¹⁾ Hackers ne signifie pas systématiquement « pirates » : en fait, les hackers originels étaient des « gentils » hackers, désignés comme white hats – chapeaux blancs – pour les distinguer des pirates (plus récents), ou black hats – chapeaux noirs. Il existe toujours ces deux types de hackers : les premiers avertissent les éditeurs de logiciels/d’applications et fournisseurs de ressources lorsqu’ils découvrent une faille de sécurité, et ne l’exploitent pas. Les seconds ne préviennent pas et exploitent les failles pour voler des informations, corrompre les données, ou faire du chantage (entre autres).

Dès le début des années 60, les mots de passe sont apparus et n’ont cessé de se complexifier et de se répandre, pour parer aux attaques de plus en plus astucieuses et fréquentes. Parallèlement, une variante moins sécurisée est constituée par les codes de passe : les codes PIN (Personal Identification Number) issus du monde bancaire (code secret de carte bancaire) et de la téléphonie mobile (code déverrouillage de carte SIM) qui sont encore souvent entièrement numériques et très (trop) courts : souvent 4 à 8 chiffres en 2023 !

Durant une longue période, l’utilisation des mots (et codes) de passe était peu contraignante, car les contraintes de complexité n’avaient pas besoin d’être importantes et chaque individu disposait de peu de comptes, donc peu de mots/codes de passe à retenir. Avec l’essor de l’économie du web (années 2000), puis des smartphones (années 2010), le nombre de comptes utilisateurs, et donc d’authentifiants, a explosé.

Historiquement, il semble que les mots de passe ont d’abord été utilisés pour authentifier des utilisateurs humains, puis, plus tard, pour identifier des ressources informatiques entre elles. Ces dernières étaient moins exposées aux risques, car le filtrage des accès par adresse IP apportait déjà une certaine sécurité, toute relative à elle seule.

Toutefois, des solutions existent pour simplifier l’utilisation (la génération et le stockage) de mots de passe pour les utilisateurs : ce sont les coffres-forts numériques (Keystore). Même si leur usage tend à se populariser ces dernières années, ce n’est pas encore systématique, notamment sur tous les supports matériels, tels que les smartphones. On peut constater des différences selon le contexte : l’usage de coffres-forts numériques est de plus en plus courant dans le cadre professionnel, encore peu répandu dans le cadre privé.

Il faut cependant rester vigilant avec les coffres-forts en ligne, qui sont certes pratiques (accès au coffre-fort depuis n’importe quel dispositif), mais sont parfois victimes de fuites de données massives car le niveau de sécurité semble très variable d’un éditeur à un autre.

Petite anecdote historique : c’est Fernando CORBATÓ (1926- 2019), prix Turing 1990, qui est considéré comme l’inventeur du mécanisme d’authentification par mot de passe au début des années 60. Plus précisément, il serait le premier à les avoir introduits dans un système informatique, car le terme « mot de passe », qui est un terme militaire, existait depuis des siècles. Cela fait donc environ 60 ans que les mots de passe existent en informatique !

Il s’agit d’une suite de mots, idéalement choisis aléatoirement, bien plus longue qu’un mot de passe, mais a priori plus aisée à retenir. Les phrases de passe (qui ressemblent à une phrase, d’où le nom de cette technique, mais ce ne sont pas réellement des « phrases ») ne sont en fait qu’un dérivatif aux mots de passe, mais elles ne sont pas inintéressantes en matière de simplicité de mémorisation, de sécurité et d’utilisabilité, si elles sont produites en respectant des contraintes strictes.

Exemples : chaton José escalier 1984 trompette bleu après-midi nuage (liste de mots sans rapport entre eux) ou JèmBi1LéCroi100&LeKf (qui correspond à la phrase « J’aime bien les croissants et le café », écrit en phonétique et Leet speak).

De manière générale, toute authentification lance un défi, celui de fournir une ou plusieurs preuves de son identité, auquel l’utilisateur, humain ou non, répond en fournissant un ou plusieurs, authentifiants. Cependant, nous souhaitons exposer ici une classe particulière de défis-réponses.

Généralement, les mots de passe et les phrases de passe sont tous deux statiques, c’est-à-dire qu’ils ne changent pas : l’utilisateur répond toujours le même authentifiant, sauf lorsqu’il le renouvelle, ce qui implique que si un pirate réussit à dérober son authentifiant (vol d’authentifiant), il pourra s’authentifier à la place de l’utilisateur, tant que celui-ci ne changera pas son authentifiant.

De même, si le pirate peut copier ce qui a été envoyé par l’utilisateur au moment de son authentification, même si cela a été envoyé dans un canal sécurisé, et le renvoyer à son tour tel quel (sans le décrypter), il pourrait s’authentifier, c’est ce qui s’appelle une attaque par rejeu, du moins si le fournisseur de ressources n’a pas prévu ce cas, car il existe des solutions pour contrer les attaques par rejeu.

Une certaine famille d’algorithmes de défis-réponses, lancent un défi que seul l’utilisateur peut relever, et ce défi change à chaque authentification, on parle aussi de mots de passe à usage unique (ou OTP = One Time Password), dans ce cas l’authentifiant doit avoir une durée de validité finie, temporellement courte, de quelques minutes à quelques heures, et/ou obsolète après sa première utilisation.

Cette famille de défis-réponses peut prendre de nombreuses formes. Vous trouverez ci-dessous quelques exemples simplifiés, qui ont le mérite d’éclairer sur les principes sous-jacents :

• Algorithme naïf : l’utilisateur et le fournisseur de ressources disposent d’une (longue) table de correspondances (numéros <=> mots de passe) qui est un secret partagé. Le fournisseur de ressources choisit un numéro au hasard, en excluant ceux déjà choisis précédemment, puis le présente comme défi. L’utilisateur doit renvoyer le mot de passe correspondant au numéro, ainsi le mot de passe change à chaque authentification ;
• L’utilisateur et le fournisseur partagent un algorithme déterministe de génération qui est le secret partagé. Cela se présente comme une formule mathématique, généralement issue de la théorie des nombres et de la cryptologie. Le fournisseur choisit un nombre aléatoire en excluant ceux déjà utilisés précédemment et le présente comme défi, l’utilisateur introduit ce nombre dans sa formule et renvoie le résultat, le fournisseur peut aisément vérifier le résultat de son côté avec sa copie de la formule ;
• Certains de ces algorithmes peuvent également se baser sur le moment précis de l’authentification (date et heure à la milliseconde, par exemple) en le transformant, afin de produire un authentifiant unique, en utilisant ici aussi une formule mathématique déterministe (on parle plus précisément ici de TOTP : Time-based One Time Password).

On constate qu’avec de tels systèmes, le point d’achoppement principal est qu’il faut préalablement partager un secret, et le protéger : la formule mathématique, ou les paramètres de cette formule, permettant au client de produire la même réponse que côté fournisseur du service. Le second point crucial est d’employer une formule suffisamment résistante ne pouvant être devinée, même si l’on dispose d’un grand nombre de couples défi-réponse issus de cette formule.

Force est de constater la plus ou moins grande complexité technique et logistique pour déployer ce type d’authentification : il faut des défis spécifiques à chaque client, donc échanger de manière parfaitement sûre, et préalablement, un secret partagé différent avec chaque client, et changer régulièrement ce secret partagé (avec chaque client).

Ce système est un peu plus complexe à employer qu’un mot de passe statique pour un utilisateur (humain), c’est pourquoi ce type d’authentification est utilisé plus couramment entre des systèmes (matériels et logiciels) informatiques, par exemple : entre un navigateur web et un serveur web, entre deux logiciels ou systèmes… En effet, ce nombreux protocoles informatiques reposent sur des phases de défis-réponses (TLS = le ‘S’ de HTTPS, SSH = le ‘S’ de SFTP, Kerberos, certificats Let’s Encrypt, etc.), notamment dans leur phase initiale de « handshake » (poignée de main), au tout début de l’établissement d’une connexion sécurisée. Cependant, concevoir et implémenter un tel système parfaitement sûr est très ardu, et même les équipes d’experts qui ont spécifié ces standards, ont parfois laissé passer des failles, sans compter les erreurs liées aux implémentations de ces standards.

Il y a toutefois quelques cas de défi-réponse effectivement mis en place avec des utilisateurs :

• Certains fournisseurs de ressources proposent ce type de mécanismes d’authentification, par exemple dans les processus de récupération d’authentifiants perdus, afin de vérifier l’identité des utilisateurs. Exemples : les comptes sur Windows 10 et 11 (trois questions et réponses), ou sur certains sites web. Mais chacun propose toujours les mêmes défis prédéfinis, ils ne sont, par conséquent, pas fondamentalement plus sûrs qu’un mot de passe ;
• Il existe des moyens simplifiant l’usage des défis-réponses par des utilisateurs : les jetons d’authentification matériels ou logiciels (que nous aborderons dans la partie suivante) ;
• Ou encore pour des usages militaires où la sécurité passe avant toute autre considération telle que l’expérience utilisateur.

Il existe d’autres formes plus élaborées de défis-réponses, généralement issues du monde de la cryptologie : les preuves à divulgation nulle de connaissance (Zero Knowledge Interactive Proof) qui se comportent de manière similaire à des défis-réponses (dans le principe mais pas dans la manière). Ces formes sont également essentiellement utilisées entre systèmes informatiques (un navigateur web et un site web par exemple), rarement entre des utilisateurs (humain) et une ressource, nous ne les détaillerons pas ici.