Authentification : les mots de passe ont la vie dure !

Catégorie(s) : Actualités, Sécurité - RGPD

Dans ce dossier divisé en quatre parties, nous vous proposons de parcourir les nombreuses problématiques liées à l’authentification, en passant en revue les atouts et faiblesses des principales familles de mécanismes d’authentification, tout en essayant dêtre le plus général et simple possible, afin de rester accessible au plus grand nombre. Vaste programme, mais défi intéressant !

Retrouvez également les autres articles de ce dossier :

Il existe un grand nombre de scénarios d’authentification, en fonction des besoins, contextes et des environnements, ce dossier ne pourra évidemment pas tous les aborder : il se concentrera sur l’authentification d’entités clientes (utilisateurs humains et non humains) auprès de ressources informatiques (matérielles et logicielles, locales ou distantes), sans toutefois aller jusqu’à la gestion des habilitations (qui est un autre sujet). L’un des objectifs de ce dossier est d’étudier chaque principale famille de mécanisme d’authentification, afin d’en synthétiser les points forts et points faibles.

Voici un aperçu des scénarios d’authentification, et de ceux traités dans ce dossier :

  • Authentification d’utilisateurs (humains) auprès d’une ressource informatique, dans le cadre du contrôle d’accès : c’est le sujet principalement abordé dans cet article ;
  • Authentification d’entités non humaines (matérielles et logicielles) auprès d’une ressource informatique, dans le cadre du contrôle d’accès : partiellement abordée dans cet article ;
  • Gestion des authentifications d’entités non humaines (matériels ou logiciels) coté serveurs, c’est-à-dire des systèmes informatiques qui s’authentifient entre eux : non directement abordée dans cet article, même si certains des éléments leur sont également applicables ;
  • Authentification de messages & documents (signatures numériques) : non abordée dans cet article.

Les problématiques des systèmes d’authentification

À ce jour, le système d’authentification le plus répandu, mais également l’un des plus décriés, est l’authentification par mots de passe, cela concerne les utilisateurs (humains) pour se connecter à des systèmes ou services (locaux ou en ligne) et également les connexions entre systèmes informatiques (mode « client – serveur »).

La mise en pratique d’une authentification à destination d’utilisateurs (humains) doit concilier, autant que faire se peut, plusieurs exigences parfois antagonistes :

  1. Assurer une sécurité sans faille(s), ou plus clairement : toujours authentifier les utilisateurs légitimes, uniquement eux, et protéger l’accès à leur(s) compte(s) ;
  2. Respecter les législations autour des systèmes d’authentification, par exemple pour les services bancaires, il existe la Directive Européenne DSP2 ;
  3. Respecter les législations autour de la vie privée et des données personnelles (RGPD et ePrivacy), et minimiser la collecte des données personnelles au strict nécessaire (principe trop souvent galvaudé) ;
  4. Et tout cela sans (trop) amoindrir l’expérience utilisateur, ou plus clairement : en imposant des contraintes et inconvénients acceptables pour les utilisateurs (humains), mais en gardant à l’esprit que ceci devrait dépendre (normalement) d’abord de la criticité des informations à protéger, des risques qu’elles encourent, et ne devrait dépendre que secondairement du niveau de compétence individuelle des utilisateurs.

La sécurisation des accès est une obligation en matière de Sécurité des Systèmes d’Information (SSI), et c’est même une obligation légale dans le cadre du RGPD, lorsque des données personnelles sont en jeu (ce qui est pratiquement toujours le cas), sachant qu’il y a également d’autres textes législatifs abordant ce sujet.

Sans oublier que l’expérience utilisateur (= facilité d’utilisation) est importante pour ne pas dissuader les utilisateurs humains, voire les pousser à délaisser le service ou pire, à chercher des moyens de contourner les mesures de sécurité. Toutefois, elle ne doit pas prendre le pas sur la SSI, trop critique (surtout ces dernières années). La moindre faille peut en effet avoir des impacts extrêmement négatifs : sur l’image de l’organisme, la confiance envers celui-ci mais aussi concernant les aspects technique, pénal, financier, etc.

Exception notable : l’expérience utilisateur n’entre pas en ligne de compte dans le cas de systèmes informatiques qui s’authentifient entre eux : on parle parfois d’authentification applicative. D’autres considérations sont toutefois à prendre en compte, comme le fait que ces derniers s’authentifient plus fréquemment, qu’ils restent connectés sur de très longues périodes, que leurs authentifiants sont changés moins souvent, et qu’il existe parfois des contraintes ou limitations techniques.

Pour en revenir à l’authentification des utilisateurs (humains), toute la difficulté est de trouver un compromis acceptable, mais sans affaiblir la SSI, tout en sachant que ce qui acceptable pour un utilisateur, ne le sera pas nécessairement par un autre. Mais pour autant, il ne faut pas niveler la SSI par le bas (par les maillons les plus faibles).

Enfin, il faut tenir compte des risques liés au contexte : un accès utilisateur, qui est limité à une petite portion d’informations, en lecture seule, n’induit pas le même niveau de risques qu’un logiciel qui accède à la totalité d’une base de données, en lecture et écriture.

Le vocabulaire autour de l’authentification

Avant d’aborder plus en détail les différents mécanismes d’authentification, il est important de bien comprendre les termes qui sont associés à cette thématique :

  • Le terme identification se distingue de l’authentification, les deux sont complémentaires afin d’établir une session d’échanges d’informations entre un client (ou prouveur) et une ressource informatique matérielle ou logicielle (ou vérifieur).
  • Le prouveur peut être un utilisateur (humain) ou un système informatique au sens le plus large (un matériel, un logiciel, une application). Les cas d’utilisation peuvent être les suivants :
    • Utilisateur (humain) : connexion à des sites web, à un smartphone, à un ordinateur, à une box Internet, à ses comptes clients, etc.
    • Système informatique : une interface graphique qui se connecte à une base donnée, une application de messagerie à un serveur, un ordinateur qui se connecte au réseau d’entreprise, un smartphone qui se connecte à un réseau mobile ou Wi-Fi, etc.
  • Les ressources informatiques auxquelles on accède (i.e. côté vérifieur) peuvent être locales ou distantes, et peuvent prendre des formes extrêmement variées telles que : l’ouverture de session (sur un smartphone ou sur un ordinateur), l’exécution d’applications ou de logiciels et toutes sortes de services locaux ou en ligne (partages de fichiers, cloud de stockage ou de traitement, comptes bancaires/santé, etc., messageries/réseaux sociaux, streaming, jeux, sites marchands…)
  • L’identifiant, également désigné login, est une information qui n’est pas intrinsèquement secrète, mais qui peut être confidentielle (par exemple s’il s’agit d’un numéro de compte bancaire ou une adresse courriel). Il identifie le prouveur (un utilisateur ou un système informatique), toutefois, l’identifiant ne garantit absolument pas que le prouveur est bien celui qu’il prétend être.
    • Dans le cas d’utilisateurs, l’identifiant peut être un simple code (numérique ou autre, tel qu’un code client), un nom ou un pseudonyme (« vivi » par exemple, le problème est que beaucoup d’utilisateurs peuvent potentiellement avoir le surnom « vivi » ), ou plus fréquemment une adresse courriel. L’adresse courriel a un atout évident : il ne peut y avoir deux personnes utilisant une même adresse nominative, toutefois elle a aussi un inconvénient : c’est une donnée personnelle (si elle est nominative).
    • Remarques concernant les adresses courriel : certaines adresses n’identifient pas nominativement une personne physique (par exemple contact@societe.fr). De plus, bien qu’à un instant donné deux individus ne peuvent avoir la même adresse courriel, à des périodes différentes ce n’est pas exclu (si une personne quitte un organisme, et un homonyme de cette personne arrive quelques années après, il est possible que cette dernière ait la même adresse que la première).
  • L’authentifiant est quant à lui constitué d’une (ou plusieurs) information(s) secrète(s), et même hautement confidentielle(s), servant à démontrer au vérifieur que le prouveur est bien celui qu’il dit être. Cette information ne devrait être détenue que par le prouveur, et jamais stockée par le vérifieur (le système auprès duquel le client s’authentifie). Ce dernier point va peut-être en étonner certains : un prouveur n’a pas besoin de détenir l’authentifiant, il a uniquement besoin d’un moyen permettant de vérifier que le prouveur lui fournit le bon authentifiant, nuance !
    • Incidemment, si cette règle, pourtant simple à mettre en place techniquement, était scrupuleusement respectée partout (par tous les sites web, systèmes et logiciels), il y aurait beaucoup moins de conséquences néfastes lors de piratages des services en ligne : aucun authentifiant ne pourrait être volé !
    • Un authentifiant peut être de différentes natures, cela peut être quelque chose que le prouveur (utilisateur ou logiciel) connait ou qu’il sait faire (tel qu’un un mot de passe, une signature manuscrite ou un calcul) , qu’il possède (tel qu’un smartphone ou une clef USB d’authentification), qui le caractérise ou ce qu’il est (telle qu’une empreinte digitale ou une adresse MAC).
  • Nous utiliserons également une notion très utile : l’entropie (formellement l’entropie de Shannon), qui est un moyen de mesurer (et comparer) la complexité de certains authentifiants. Pour faire simple, plus l’entropie (qui se mesure en bits) est élevée, plus un authentifiant est potentiellement robuste. Il s’agit d’une formule mathématique simple, qui tient compte de la longueur et du nombre de caractères différents utilisés, il existe même des calculateurs en ligne.

Afin d’être complet, il est pertinent de préciser que :

  • L’identifiant n’a techniquement pas besoin d’être unique : c’est le couple (identifiant, authentifiant) qui doit être unique. Prenons deux utilisatrices avec le même identifiant (avec le pseudonyme « Fofo », par exemple), si elles ont chacune un authentifiant distinct, elles seront bien considérées comme deux utilisatrices distinctes par la ressource informatique. Par commodité, y compris dans la gestion des comptes, il est toutefois plus simple et préférable de ne pas autoriser ces homonymies d’identifiants, et ce quelle que soit la casse des caractères (« Fofo » et « fofo » seront considérés comme un seul identifiant).
  • L’identifiant n’est en fait pas indispensable non plus ! Il existe de nombreux exemples où seul un authentifiant est demandé (par exemple sur un smartphone avec un seul utilisateur, un système d’alarme à codes, même s’il y a plusieurs codes valides). Et même lorsqu’il y a plusieurs comptes, tant que chaque client dispose d’un authentifiant différent des autres, il sera possible de distinguer les uns des autres. Néanmoins, cela peut complexifier la gestion des comptes, et cela induit un risque (faible, mais non nul) de collision lors du choix des authentifiants : deux utilisateurs pourraient choisir le même authentifiant sur le même système, dans ce cas le second authentifiant sera rejeté (normal), et cela dévoilerait une information capitale : le second utilisateur connait donc un autre authentifiant valide que le sien ! À nouveau, il est préférable d’imposer un identifiant distinct pour chaque utilisateur.

Pour terminer ce glossaire, et puisqu’il en est question tout au long de cet article, rappelons la signification des deux sigles : SSI, qui désigne la Sécurité des Systèmes d’Information au sens le plus large (donc pas seulement la sécurité informatique), et RGPD, qui désigne le Règlement Général sur la Protection des Données.

On peut résumer la SSI en une citation (attribuée à Fernando PESSOA, employée ici dans un autre contexte) :

« Espérer le meilleur mais se préparer au pire« 

Pour parvenir à cela, il faut se mettre « à la place » de ceux qui pourraient pirater votre système, dès la phase de conception d’un système d’authentification. C’est un exercice intellectuel intéressant, qui permet souvent de réduire sensiblement les risques, même si cela repose sur une solide culture générale et technique en matière de SSI.

Les différentes étapes des processus d’authentification

Avant d’aller plus loin, il est nécessaire d’avoir une bonne vision d’ensemble du processus d’authentification.

Quel que soit le type de client (humain ou logiciel), que ce soit sur un smartphone, un ordinateur ou un serveur, le processus général d’authentification, permettant d’accéder à n’importe quelle ressource informatique (locale ou distante), est composé de quatre principales étapes :

4 principales étapes processus authentification : authentification prouveur, échanges d'information, contrôle authentifiant, accès ressources (Illustration)

À chaque étape, la sécurité doit être assurée et maximale (par le prouveur et par le vérifieur, c’est-à-dire celui qui gère la ressource à laquelle vous accédez), c’est le principe du « maillon faible » : la sécurité globale dépend avant tout de la sécurité de son maillon le plus faible. Passons en revue chaque étape :

  • À l’étape 1 : l’authentifiant peut être espionné au moment où il est saisi, soit par un tiers qui observe (comme lorsque vous composez votre code PIN ou de déverrouillage de smartphone dans la rue ou dans les transports), soit par un logiciel ou matériel qui espionne directement sur le dispositif client lui-même (tel qu’un keylogger ou screen scraping avec un smartphone ou un ordinateur). Et si l’authentifiant est trop simple, il pourra être deviné automatiquement, sans avoir besoin de vous espionner, donc très rapidement. Corolaire : on comprend aisément que si un pirate réussit à voler l’authentifiant, et que cet authentifiant est utilisé pour la connexion à plusieurs ressources (par exemple sur différents sites web), le pirate aura accès à toutes ces ressources également : c’est pour cette raison qu’il est nécessaire de disposer d’un authentifiant distinct pour chaque ressource distincte.
  • À l’étape 2 : lors des échanges avec une ressource (qu’elle soit locale, comme une application, ou distante, comme un site web), et particulièrement pendant la phase d’authentification, toutes les informations doivent être sécurisées. Ceci dépend du client et du fournisseur de la ressource : le dispositif utilisé côté prouveur (le système d’exploitation, et les logiciels/applications) doit être à jour et ne pas restreindre la sécurité, et la sécurité de la communication doit être correctement configurée par le fournisseur de la ressource (chose que le prouveur peut et doit vérifier).
    Par exemple :

    • Pour une ressource sur le web, l’utilisation du protocole HTTPS et d’un certificat serveur (tous deux à jour) sont des sécurités minimales (mais non suffisantes) ;
    • Le fournisseur de la ressource fournit parfois l’authentifiant aux nouveaux utilisateurs via un canal non sécurisé (par courriel ou par SMS), par exemple en cas de perte ou lors des renouvellements de leurs authentifiants, ce qui fait courir un risque inutile.
  • À l’étape 3 : lors de la vérification de l’authentifiant (à ce stade, cela ne dépend que du fournisseur de la ressource), celui-ci ne devrait jamais être conservé « en clair », mais sous une forme appelée « haché cryptographique » (condition nécessaire, mais non suffisante), à ne surtout pas confondre avec « haché programmatique » ou avec « chiffrement cryptographique » qui ne partagent ni les mêmes objectifs, ni les mêmes caractéristiques. De plus, d’autres sécurités doivent être mises en place, comme le blocage des comptes clients en cas d’échecs répétés d’authentification, et des alertes en cas de comportements anormaux, la journalisation de toutes les tentatives d’accès, réussies ou non.
  • À l’étape 4 : la protection des ressources (notamment les données sensibles qu’elles hébergent et/ou utilisent) doit être assurée, même lorsque le client n’est pas connecté, car de nombreux piratages s’attaquent non pas à la phase d’authentification (réussir à pirater un authentifiant d’un client ne donnera accès qu’à ses données), mais directement à l’hébergeur, ou aux ressources qu’il gère, ce qui donne accès à bien plus de données que celle d’un compte client seul.
    • À souligner : un authentifiant ne protège pas les données hébergées, mais uniquement l’accès aux données !
    • L’étape 4 est malheureusement souvent négligée par les fournisseurs de ressources, l’explosion des fuites de données en est le signe révélateur.

Il est important de souligner qu’à chaque étape, c’est le vérifieur qui impose ses choix au prouveur (complexité de l’authentification, canaux de communication, vérification), ce qui est normal : c’est le vérifieur qui a la responsabilité de sécuriser l’accès aux ressources. Toutefois, dans certains cas, il serait pertinent de proposer plusieurs (au moins deux) mécanismes d’authentification différents aux utilisateurs, et tous ces mécanismes doivent être sûrs, bien évidemment.

Dans le prochain article de ce dossier, nous nous concentrerons sur les caractéristiques nécessaires pour une authentification forte et sur les principaux mécanismes d’authentification, qui concernent les étapes 1 à 3 (et non la 4) du processus ci-dessus…

Date

10 octobre 2023

Auteur