Authentification forte : par où commencer quand on ne peut pas tout couvrir

L’authentification à plusieurs facteurs est devenue une exigence par défaut : assureurs, clients grands comptes, référentiels normatifs et régulateurs la demandent. Le déploiement, lui, reste partiel presque partout. Et la question posée aux équipes est rarement « faut-il en faire », mais « par quoi commence-t-on, avec un budget et une capacité de support limités ».

Tous les seconds facteurs ne protègent pas de la même chose

C’est le point que les discussions escamotent le plus souvent. Un second facteur ajoute une barrière, mais la nature de la barrière change tout.

• Le SMS et l’appel vocal protègent contre la réutilisation de mots de passe issus de fuites. Ils ne protègent pas contre l’interception, ni contre le détournement de ligne. Le NIST les déconseille comme facteur principal depuis plusieurs révisions de sa publication sur l’identité numérique.
• Les codes temporaires d’application résistent au détournement de ligne, mais pas à l’hameçonnage : un utilisateur qui saisit son code sur une fausse page le donne à l’attaquant, qui le rejoue dans les secondes qui suivent.
• Les notifications à valider souffrent d’un problème comportemental : un attaquant qui détient le mot de passe peut déclencher des demandes en rafale jusqu’à ce que l’utilisateur valide par lassitude ou par erreur. Le mécanisme de correspondance de numéro réduit fortement ce risque, sans l’annuler.
• Les facteurs résistants à l’hameçonnage — clés physiques et authentificateurs conformes aux spécifications FIDO2/WebAuthn — sont les seuls à traiter le problème à la racine : le secret ne quitte jamais le dispositif et l’authentification est liée cryptographiquement au domaine visité. Une fausse page ne peut pas la relayer.

Cette distinction n’est pas théorique. Les campagnes d’hameçonnage par serveur relais, qui interposent un proxy entre l’utilisateur et le service légitime, contournent les codes temporaires et les notifications sans difficulté particulière. Elles échouent contre un facteur lié au domaine.

L’ordre de déploiement

Quand on ne peut pas tout couvrir en même temps, l’ordre suivant donne le meilleur rapport entre réduction du risque et effort.

1. Les accès d’administration

Tout ce qui permet d’administrer : annuaire, hyperviseurs, sauvegardes, équipements réseau, consoles d’infrastructure hébergée, outils de déploiement. La population est réduite, techniquement à l’aise, et l’impact d’une compromission est maximal. C’est le seul périmètre où un facteur résistant à l’hameçonnage devrait être non négociable.

2. Les accès distants

Passerelles d’accès, bureaux à distance, connexions des prestataires. Historiquement le point d’entrée le plus utilisé pour les intrusions aboutissant à un chiffrement. Un accès distant exposé sans second facteur est aujourd’hui difficile à justifier devant un assureur.

3. La messagerie

Une boîte compromise sert à trois choses : lire, se faire passer pour quelqu’un, et réinitialiser d’autres accès par la fonction « mot de passe oublié ». C’est le pivot des fraudes au virement. Le volume d’utilisateurs est important, donc le facteur doit être supportable — c’est là que le compromis se joue.

4. Les applications métier sensibles

Paie, comptabilité, outils de gestion de la relation client, portails de télédéclaration. Souvent oubliées parce qu’elles ne sont pas gérées par l’informatique.

5. Les comptes de secours

Les comptes d’urgence conservés « au cas où » sont fréquemment exclus de la politique. Ils doivent l’être aussi, avec un mécanisme de recouvrement documenté et testé.

Les points qui font échouer le projet

Le recouvrement. C’est la faille la plus courante. Une procédure de réinitialisation qui repose sur un appel au support et une question sur la date de naissance annule tout le dispositif. Un attaquant compétent n’attaque pas le second facteur, il attaque la procédure qui permet de s’en passer. Le recouvrement doit être aussi exigeant que l’authentification qu’il remplace.

Les exceptions permanentes. Les dérogations accordées pendant le déploiement — pour un dirigeant, une équipe en déplacement, une application incompatible — deviennent définitives si aucune date de fin n’est fixée à l’octroi.

Les protocoles hérités. Certains protocoles d’accès anciens ne savent pas présenter de second facteur et l’ignorent purement et simplement. Tant qu’ils restent activés, le second facteur est contournable sans effort. Leur désactivation fait partie du projet, pas d’un chantier ultérieur.

Les comptes de service. Ils ne peuvent pas porter de second facteur. Ils relèvent d’un autre traitement : secrets longs et renouvelés, restriction d’origine, retrait des privilèges excessifs.

Ce qu’on gagne réellement

L’authentification forte ne supprime pas le risque de compromission de compte, elle en change la nature. Elle rend inopérantes les attaques de masse — réutilisation de mots de passe issus de fuites, essais automatisés — qui constituent l’essentiel du bruit. Elle oblige un attaquant ciblé à passer par l’hameçonnage adaptatif, le détournement de session, ou la compromission du poste. Ce sont des opérations plus coûteuses, plus lentes, et beaucoup plus détectables.

C’est un déplacement du problème vers un terrain où la détection a une chance de fonctionner. Ce n’est pas rien, mais ce n’est pas une clôture — et présenter le déploiement comme tel devant une direction générale prépare mal la conversation suivante.

Sources

• NIST — SP 800-63B, Digital Identity Guidelines, sur la robustesse comparée des facteurs d’authentification
• ANSSI — recommandations relatives à l’authentification multifacteur et aux mots de passe
• Alliance FIDO — spécifications FIDO2 / WebAuthn
• CISA — orientations sur l’authentification résistante à l’hameçonnage