Niveaux d’assurance d’authentification : ce qu’il faut pour monter d’un cran

« Nous avons mis du multifacteur » est une phrase qui ne dit presque rien. Un code à six chiffres reçu par message, une application qui affiche un nombre à recopier et une clé de sécurité matérielle sont trois dispositifs à deux facteurs, et ils n’arrêtent pas les mêmes attaques. L’échelle qui sert de référence internationale pour trancher est celle des niveaux d’assurance d’authentification du NIST, dont la quatrième révision a été publiée en juillet 2025. Elle a le mérite de dire, pour chaque niveau, quels dispositifs sont admis, ce qui est interdit, et combien de temps une session peut durer.

→ Lire l’explication complète de la marmotte

Ce que mesure un niveau d’assurance

Le document le formule en termes de confiance, et la progression tient en trois adjectifs. Le niveau 1 « fournit une confiance de base dans le fait que le réclamant contrôle un authentificateur lié au compte ». Le niveau 2 en « fournit une confiance élevée » et exige « la preuve de possession et de contrôle de deux facteurs d’authentification distincts ». Le niveau 3 en « fournit une confiance très élevée » et repose sur « la preuve de possession d’une clé au moyen d’un protocole cryptographique », avec une exigence qui ferme à elle seule des familles entières de produits : « l’authentification au niveau 3 requiert l’usage d’un authentificateur cryptographique avec une clé privée non exportable, qui fournit la résistance à l’hameçonnage ».

Une précision du document mérite d’être retenue, parce qu’elle contredit une pratique courante : les indicateurs de fraude, position géographique inattendue, bloc d’adresses d’un fournisseur de nuage, peuvent servir à réduire le risque, mais « l’usage d’indicateurs de fraude potentielle avant ou pendant le processus d’authentification n’impacte ni ne change le niveau d’assurance d’une transaction, et ne remplace pas un facteur d’authentification ». Un dispositif d’analyse comportementale, aussi sophistiqué soit-il, n’ajoute pas un facteur ; il ne fait que trier. La détection de connexions anormales décrite dans l’impossible travel est utile, et elle ne fait pas monter d’un cran.

Autre nuance, souvent ignorée : les exigences de validation cryptographique « sont souvent différentes pour les authentificateurs et pour les vérificateurs, les exigences les plus strictes s’appliquant généralement aux vérificateurs ». La raison est explicitée, et elle est d’une lucidité appréciable : il y a « des limitations pratiques à la certification des authentificateurs », et « une portée plus large est souvent associée à une brèche chez un vérificateur ». Casser un authentificateur donne un compte, casser un vérificateur donne tout le monde.

Les types admis, niveau par niveau

Au niveau 1, sept types sont acceptés, et il vaut la peine de les lire pour mesurer l’étendue de ce qui est permis : le mot de passe, c’est-à-dire « un secret mémorisable typiquement choisi par l’abonné » ; le secret à consulter, où le réclamant lit une valeur dans une liste qu’il détient ; l’appareil hors bande, où un secret passe par un canal séparé ; le mot de passe à usage unique à un facteur ; le mot de passe à usage unique multifacteur, qui demande un second facteur pour s’activer ; et l’authentification cryptographique, à un ou deux facteurs. Un seul facteur suffit, même si le document recommande de proposer le multifacteur et d’en encourager l’usage.

Au niveau 2, il faut « soit un authentificateur multifacteur, soit une combinaison de deux facteurs distincts ». Dans le second cas, la combinaison « DOIT inclure un authentificateur physique », c’est-à-dire quelque chose qu’on possède, associé soit à un mot de passe soit à une comparaison biométrique. Et le document pose la règle qui tranche un débat récurrent : « une caractéristique biométrique n’est pas reconnue comme un authentificateur à elle seule ». Il faut qu’un authentificateur physique soit authentifié en même temps que la comparaison biométrique ; celui-ci sert alors de « quelque chose qu’on a » et la correspondance biométrique de « quelque chose qu’on est ». Le document ajoute une préférence utile : la vérification locale du facteur biométrique, où la biométrie sert à activer un authentificateur multifacteur, « est préférée à la comparaison biométrique centrale ». Autrement dit, l’empreinte qui déverrouille une clé sur l’appareil vaut mieux que l’empreinte envoyée à un serveur.

Au niveau 3, deux combinaisons seulement : l’authentification cryptographique multifacteur, ou l’authentification cryptographique à un facteur associée à un mot de passe ou à une comparaison biométrique. S’y ajoutent des contraintes matérielles qui excluent beaucoup de choses. L’authentificateur « DOIT avoir une clé privée non exportable », le protocole « DOIT résister au rejeu », et tous les processus d’authentification et de réauthentification « DOIVENT démontrer l’intention d’authentification depuis au moins un authentificateur », c’est-à-dire exiger un geste. Les authentificateurs doivent fournir « un environnement isolé et protégé par le matériel pour empêcher les clés d’authentification de fuir ou d’être extraites », exigence proche de celle des enclaves sécurisées. Et surtout, une phrase qui a fait du bruit dans le monde des clés d’accès : « puisque les authentificateurs synchronisables requièrent que la clé privée soit exportable, les authentificateurs synchronisables NE DOIVENT PAS être utilisés au niveau 3 ». Une clé d’accès synchronisée entre les appareils d’un utilisateur est excellente, et elle ne permet pas d’atteindre le niveau 3. Le document recommande en outre que les authentificateurs matériels et les vérificateurs de ce niveau « résistent aux attaques par canaux auxiliaires pertinentes, par exemple l’analyse temporelle et celle de consommation », sujet de les attaques par canaux auxiliaires.

La résistance à l’hameçonnage, définie techniquement

C’est la partie la plus utile du document, parce qu’elle remplace un adjectif commercial par une propriété vérifiable. La définition : « la résistance à l’hameçonnage est la capacité du protocole d’authentification à empêcher la divulgation des secrets d’authentification et des sorties valides d’authentificateur à un vérificateur imposteur, sans dépendre de la vigilance du réclamant ». Les quatre derniers mots sont l’essentiel : une mesure qui repose sur la capacité de l’utilisateur à repérer un faux site n’est pas une mesure de résistance à l’hameçonnage. Le document ajoute que « la manière dont le réclamant est dirigé vers le vérificateur imposteur n’est pas pertinente » : référencement, courriel, peu importe, c’est un hameçonnage.

Suit l’exclusion qui règle le sort de la plupart des dispositifs déployés : « les authentificateurs qui impliquent la saisie manuelle d’une sortie d’authentificateur, par exemple les authentificateurs hors bande et à mot de passe à usage unique, NE DOIVENT PAS être considérés comme résistants à l’hameçonnage, parce que la saisie manuelle ne lie pas la sortie de l’authentificateur à la session spécifique qui est authentifiée ». Et l’explication du pourquoi : « un vérificateur imposteur pourrait relayer une sortie d’authentificateur vers le vérificateur et s’authentifier avec succès ». Tout code qu’un humain recopie est un code qu’un intermédiaire peut faire recopier chez lui, ce qui est exactement le mécanisme de l’attaque de l’intercepteur appliqué à l’authentification. Code reçu par message, code lu dans une application, code reçu par courriel : aucun n’est résistant à l’hameçonnage, et le cas du second facteur par courriel contourné est illustré par l’incident DGFiP.

Deux méthodes seulement produisent cette propriété. La liaison au canal établit un canal protégé authentifié, puis « lie fortement et irréversiblement un identifiant de canal, négocié lors de l’établissement du canal, à la sortie de l’authentificateur », par exemple en signant les deux valeurs ensemble. Le bénéfice est précis : cela empêche un vérificateur imposteur, « même s’il a obtenu un certificat qui représente le vérificateur réel, de relayer cette authentification sur un canal différent ». L’exemple donné est le TLS avec authentification du client, mécanisme détaillé dans les jetons liés au certificat client. La liaison au nom du vérificateur lie cryptographiquement la sortie de l’authentificateur « à un identifiant de vérificateur qui est authentifié dans le cadre du protocole » ; pour un nom de domaine, cet identifiant « DOIT être soit le nom d’hôte authentifié du vérificateur, soit un domaine parent situé au moins un niveau sous le suffixe public associé ». L’exemple est WebAuthn, « qui fournit la résistance à l’hameçonnage par liaison au nom du vérificateur en choisissant un secret d’authentificateur fondé sur le nom de domaine authentifié du vérificateur », et dont le déploiement est l’objet de WebAuthn FIDO2.

Le document précise laquelle des deux est la meilleure, et pourquoi : « la liaison au canal est considérée comme plus sûre que la liaison au nom du vérificateur, parce qu’elle n’est pas vulnérable à la mauvaise émission ou à l’appropriation abusive des certificats du vérificateur », les deux satisfaisant néanmoins l’exigence. On retrouve ici la faiblesse du « ou » logique entre autorités de certification, illustrée par l’affaire DigiNotar. À noter enfin, pour les organisations qui se demandent si l’exigence est raisonnable : au niveau 2, les vérificateurs « DOIVENT offrir au moins une option d’authentification résistante à l’hameçonnage », et les agences fédérales américaines « DOIVENT exiger » de leur personnel, de leurs prestataires et de leurs partenaires qu’ils l’utilisent. Le choix des facteurs pour les comptes sensibles est traité dans le déploiement de FIDO2 pour les comptes à privilèges.

Les durées de session, et ce qu’elles coûtent

C’est la dimension qu’on oublie en concevant une authentification, et elle fait partie du niveau. Le document distingue deux temporisations : une globale, qui « limite la durée d’une session authentifiée à une période spécifique suivant l’authentification ou une réauthentification précédente », et une d’inactivité, qui « termine une session sans activité de l’abonné pendant une période spécifique ». L’activité remet à zéro la seconde ; une réauthentification réussie remet à zéro les deux. À l’expiration de l’une ou l’autre, « la session DOIT être terminée ».

Les valeurs par niveau sont explicites. Au niveau 1, la temporisation globale « ne DEVRAIT pas excéder 30 jours » et celle d’inactivité est facultative. Au niveau 2, la globale « ne DEVRAIT pas excéder 24 heures » et l’inactivité « ne DEVRAIT pas excéder 1 heure » ; une concession pratique est prévue, puisque lorsque l’inactivité a expiré mais pas la globale, le vérificateur « PEUT permettre à l’abonné de se réauthentifier en utilisant seulement un mot de passe ou une comparaison biométrique réussie, en conjonction avec le secret de session ». Au niveau 3, la globale « DOIT ne pas excéder 12 heures », l’inactivité « ne DEVRAIT pas excéder 15 minutes », et surtout : « contrairement au niveau 2, les exigences de réauthentification au niveau 3 sont les mêmes que pour l’authentification initiale ». Pas de raccourci, pas de mot de passe seul : la clé, le geste, à chaque fois.

Le document reconnaît que ces limites dépendent du contexte, « l’environnement dans lequel la session se déroule, le type de point d’accès utilisé, le fait que l’appareil soit géré ou non, et la nature de l’application elle-même », et qu’elles « PEUVENT être étendues quand des technologies de maintien de session plus sûres, par exemple des mécanismes liés à l’appareil, sont utilisées ». Il exige en revanche que ces limites soient établies et documentées.

Une dernière remarque, qui concerne tout déploiement fédéré : « des considérations particulières s’appliquent à la gestion de session et à la réauthentification lors de l’usage d’un protocole de fédération », car le fournisseur d’identité et le service consommateur « gèrent les sessions séparément l’un de l’autre et le protocole de fédération ne connecte pas les sessions ». C’est la raison pour laquelle une déconnexion chez le fournisseur ne ferme pas les sessions ouvertes ailleurs, et la même raison pour laquelle une réinitialisation de mot de passe ne coupe pas une session en cours, comme l’a montré l’incident DGFiP. Le reste du cycle de vie des sessions est traité dans la durée de vie des jetons OAuth et l’articulation des niveaux dans les niveaux d’assurance de fédération.

Sources

NIST SP 800-63B-4 : Digital Identity Guidelines, Authentication and Authenticator Management, NIST, juillet 2025.

🐝 Ce qui arrive si on s’en passe

Sans échelle de référence, « nous avons du multifacteur » recouvre un code recopié à la main et une clé matérielle, et aucune décision de risque ne peut s’appuyer sur cette phrase. Sans facteur résistant à l’hameçonnage, un intermédiaire relaie le code que l’utilisateur recopie et s’authentifie à sa place, quelle que soit la vigilance de celui-ci. Sans clé privée non exportable, un authentificateur synchronisé entre appareils reste excellent contre l’hameçonnage mais ne permet pas d’atteindre le niveau le plus élevé, et le croire conduit à surestimer la protection des comptes les plus sensibles. Sans exigence d’intention d’authentification, une clé branchée en permanence répond à toute demande, y compris celles qu’un code hostile émet en arrière-plan. Sans temporisation globale et d’inactivité documentées, une session authentifiée une fois reste ouverte des semaines, et la force du facteur initial perd tout intérêt. Et sans conscience que les sessions d’un fournisseur d’identité et celles d’un service sont indépendantes, une déconnexion ou une réinitialisation ne coupe rien.

🦫 Explication de la marmotte 🍫

Dire qu’un compte est protégé par deux facteurs ne dit pas grand-chose, parce que les dispositifs disponibles n’arrêtent pas les mêmes attaques. Les recommandations américaines définissent donc trois niveaux, et précisent pour chacun ce qui est permis.

Au premier niveau, un mot de passe seul suffit. Au deuxième, il faut deux éléments de nature différente, par exemple quelque chose qu’on possède et un mot de passe. Une empreinte digitale, à elle seule, n’est jamais acceptée comme facteur : il faut qu’elle serve à activer un appareil qu’on possède. Au troisième niveau, il faut un appareil contenant une clé secrète qui ne peut pas être extraite, et il faut faire un geste à chaque usage.

Le point le plus utile du document est sa définition de la résistance à l’hameçonnage : la capacité du mécanisme à empêcher qu’un faux site obtienne de quoi se connecter à votre place, sans compter sur votre vigilance. Cette définition a une conséquence immédiate et dérangeante : tout code que vous recopiez à la main n’est pas résistant à l’hameçonnage. Un code reçu par message, lu dans une application ou reçu par courriel peut être demandé par un faux site, qui le relaie aussitôt au vrai. Seules deux techniques fonctionnent, et toutes deux reposent sur le fait que l’appareil, et non l’utilisateur, vérifie à qui il parle.

Dernier élément du niveau, souvent oublié : la durée des sessions. Une session ne doit pas rester ouverte indéfiniment, et les durées maximales recommandées diminuent avec le niveau : un mois au premier, un jour au deuxième avec une heure d’inactivité, douze heures au troisième avec un quart d’heure d’inactivité et une nouvelle authentification complète. Un facteur très solide utilisé une fois, suivi d’une session de trois semaines, ne protège pas beaucoup plus qu’un mot de passe.

Pages voisines

La citent

Niveaux d'assurance d'authentification : ce qu'il faut pour monter d'un cran

Elle cite

: les deux pages se citent l’une l’autre.