Une porte, un badge, et la question « qui es-tu ? »

À l'entrée du personnel du centre commercial « Les Arcades », il y a une porte discrète sur le côté du bâtiment. Pas de vitrine, pas de flux de clients, juste un sas, un lecteur de badge et un vigile derrière une vitre. Chaque employé qui arrive le matin doit répondre à une seule question avant de franchir le sas : qui es-tu ?

Cette question paraît banale. Elle est pourtant le point de départ de toute la sécurité du bâtiment. Si n'importe qui peut se présenter comme « le responsable de la bijouterie » sans le prouver, alors les rideaux de fer, les coffres et la vidéosurveillance ne servent plus à grand-chose. La première barrière n'est pas une serrure, c'est la preuve d'identité.

Avant de décider ce qu'une personne a le droit de faire, un système doit d'abord établir, de façon fiable, qui elle est. Tout le reste en dépend.

En informatique, cette porte du personnel s'appelle l'authentification. Ce billet déroule la notion de bout en bout : la différence entre prouver son identité et obtenir des droits, les trois familles de facteurs (ce qu'on sait, ce qu'on possède, ce qu'on est), pourquoi un seul facteur est fragile, comment le MFA renforce la porte, pourquoi tout MFA ne se vaut pas, l'attaque par « MFA fatigue » qui a touché Uber en 2022, et enfin le SSO, ce badge unique qui ouvre plusieurs boutiques sans se réauthentifier partout.

Authentification n'est pas autorisation

Deux mots reviennent sans arrêt et on les confond souvent. Au sas du personnel, ils correspondent à deux moments distincts.

L'authentification (souvent abrégée AuthN) répond à « qui es-tu ? ». Le vigile vérifie que la personne en face est bien Camille, responsable de la bijouterie, et pas quelqu'un qui se fait passer pour elle.

L'autorisation (AuthZ) répond à « qu'as-tu le droit de faire ? ». Une fois Camille reconnue, son badge ouvre la réserve de la bijouterie et le local technique de son étage, mais pas le bureau du directeur ni la salle des coffres. C'est le moindre privilège : chacun reçoit juste les accès nécessaires à son rôle, rien de plus.

Authentifier, c'est établir l'identité. Autoriser, c'est accorder des droits à une identité déjà établie. On ne peut pas autoriser correctement quelqu'un qu'on n'a pas d'abord authentifié.

Ce billet traite uniquement de la première moitié, l'authentification. La gestion fine des droits, des comptes à privilèges et du cycle de vie des identités fait l'objet d'un sujet à part entière (IAM et PAM). Garder les deux notions séparées dans sa tête évite beaucoup de confusions, et c'est d'ailleurs un réflexe central de l'approche Zero Trust : ne jamais accorder un accès sans avoir vérifié explicitement l'identité, à chaque demande, sans confiance implicite.

Les trois familles de facteurs

Comment prouver qu'on est bien Camille ? Il n'existe que trois grandes catégories de preuves, et toute la suite repose sur elles. On les appelle des facteurs d'authentification.

  • Ce qu'on sait (facteur de connaissance) : une information mémorisée. Au sas, c'est le code PIN à taper sur le clavier. En informatique, c'est le mot de passe, le code PIN, la réponse à une question secrète.
  • Ce qu'on possède (facteur de possession) : un objet physique qu'on détient. Au sas, c'est le badge magnétique. En informatique, c'est le téléphone qui reçoit un code, une application d'authentification, une clé de sécurité USB.
  • Ce qu'on est (facteur d'inhérence) : une caractéristique biométrique propre à la personne. Au sas, c'est le lecteur d'empreinte digitale à côté de la porte. En informatique, c'est l'empreinte, le visage, parfois la voix.

Le tableau ci-dessous résume les trois familles, leur version « Les Arcades » et leur transposition technique, avec leur point faible respectif.

Famille Au sas du personnel En informatique Point faible principal
Ce qu'on sait Code PIN du clavier Mot de passe, code PIN Se devine, se vole, se rejoue, se réutilise partout
Ce qu'on possède Badge magnétique Téléphone, clé de sécurité, app TOTP Peut être perdu, prêté, cloné selon la techno
Ce qu'on est Empreinte digitale Empreinte, visage, voix Ne se change pas si compromis, faux positifs possibles
Un facteur fort dans une famille ne compense pas l'absence des autres. La robustesse vient de la combinaison de familles différentes, pas de l'empilement de preuves du même type.

Deux mots de passe ne forment pas une authentification à deux facteurs : ils appartiennent tous les deux à « ce qu'on sait ». De même, un code PIN plus une question secrète restent un facteur unique. La distinction entre familles est ce qui rend la suite intéressante.

Pourquoi un seul facteur ne suffit plus

Pendant longtemps, l'entrée du personnel n'a demandé qu'un code PIN. C'est commode, mais ce facteur unique cumule les faiblesses, et le mot de passe en informatique souffre exactement des mêmes.

Un code se devine quand il est trop simple. Il se vole par-dessus l'épaule, sur un post-it ou par un faux agent d'entretien qui le réclame poliment. Il se rejoue : une fois capté, il fonctionne autant de fois qu'on veut. Et surtout, les gens réutilisent le même code partout, si bien qu'une fuite chez un commerçant voisin donne la clé de la porte du personnel.

C'est précisément le scénario des fuites massives de mots de passe. Quand une base d'identifiants se retrouve en ligne, les attaquants la rejouent automatiquement contre des centaines d'autres services, en pariant sur la réutilisation. Cette attaque porte un nom, le credential stuffing, et elle marche parce que le facteur de connaissance, seul, ne prouve pas grand-chose.

Un mot de passe prouve seulement que quelqu'un connaît le mot de passe, pas que c'est la bonne personne. Dès qu'il fuite, l'authentification s'effondre entièrement.

La parade n'est pas un mot de passe « encore plus long ». C'est d'ajouter une preuve d'une autre famille, pour qu'un secret volé ne suffise plus à lui seul.

Le MFA : combiner au moins deux familles

L'authentification multifacteur (Multi-Factor Authentication, MFA) consiste à exiger au moins deux facteurs issus de familles différentes. Aux Arcades, le sas a été mis à niveau : il faut désormais le badge (ce qu'on possède) et le code PIN (ce qu'on sait). Voler le badge ne suffit plus, deviner le code non plus.

L'intérêt est arithmétique. Pour entrer frauduleusement, un attaquant doit désormais réunir deux preuves de natures distinctes au même moment. Subtiliser un badge dans un vestiaire est une chose, connaître en plus le PIN de son propriétaire en est une autre. La barrière monte d'un cran.

Le schéma suivant montre la décision prise à la porte selon les facteurs présentés.

flowchart TD A["Demande d'accès au sas"] --> B{"Facteur 1 : badge valide ?"} B -->|"Non"| R["Accès refusé"] B -->|"Oui"| C{"Facteur 2 : PIN correct ?"} C -->|"Non"| R C -->|"Oui"| D["Deux familles différentes vérifiées"] D --> E["Accès autorisé"] classDef ok fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef deny fill:#a0413e,stroke:#8a4d16,color:#f5f2ec; classDef step fill:#ede9e1,stroke:#b5651d,color:#1a1a1a; class A,B,C,D step; class E ok; class R deny;

Le cadre de référence sur ce sujet est la publication NIST SP 800-63B sur les identités numériques. Elle définit des niveaux d'assurance d'authentification (Authentication Assurance Levels, AAL) : plus le niveau est élevé, plus les exigences sur les facteurs et leur résistance aux attaques sont strictes. Un service sensible vise un AAL plus haut qu'un forum de loisir, et le MFA est une condition pour franchir ces niveaux.

Le MFA ne supprime pas le risque, il augmente le coût de l'attaque. C'est suffisant contre la majorité des compromissions opportunistes, qui cherchent la cible la plus facile.

Tout MFA ne se vaut pas

Voici le piège : dire « j'ai activé le MFA » ne dit pas grand-chose tant qu'on ne précise pas quel second facteur. Les méthodes de possession les plus répandues n'offrent pas la même résistance, en particulier face au hameçonnage (phishing).

Reprenons le sas. Imaginons plusieurs façons de fournir le second facteur, du plus faible au plus solide.

  • Code par SMS (OTP) : le sas envoie un code par message sur le téléphone. Problème, ce message peut être détourné (échange de carte SIM frauduleux, le SIM swapping) ou lu par un attaquant qui a piégé la victime sur un faux portail. Le NIST déconseille depuis plusieurs éditions de s'appuyer sur le SMS comme facteur de référence.
  • Code temporaire (TOTP) : une application génère un code à six chiffres qui change toutes les trente secondes. Plus robuste que le SMS car rien ne transite par le réseau opérateur, mais le code reste recopiable par la victime sur un faux site qui le relaie aussitôt au vrai service.
  • Notification push : le sas envoie une demande d'approbation sur l'application, la personne appuie sur « Approuver ». Pratique, mais cette validation d'un simple geste ouvre la porte à une attaque spécifique que l'on détaille plus bas.
  • Clé de sécurité FIDO2 / WebAuthn : un dispositif cryptographique (clé physique ou passkey stockée dans l'appareil) qui signe une preuve liée au domaine exact du service. Il ne révèle aucun secret recopiable et refuse de fonctionner sur un faux domaine.

Le tableau récapitule la résistance au hameçonnage de chaque méthode.

Second facteur Famille Résistant au phishing Limite principale
OTP par SMS Possession Non SIM swapping, code recopiable, interception
Code TOTP (app) Possession Non Code recopiable sur un faux portail
Notification push (approbation) Possession Non Vulnérable à la lassitude (MFA fatigue)
FIDO2 / WebAuthn / passkey Possession Oui Coût matériel, déploiement à organiser

La différence décisive tient en une notion : la résistance au hameçonnage. Un facteur y résiste quand il refuse, par construction, de divulguer une preuve réutilisable à un site qui n'est pas le bon. C'est le cas de FIDO2 et WebAuthn, standardisés par la FIDO Alliance et par le W3C, parce que la signature produite est liée cryptographiquement au domaine d'origine.

La question utile n'est pas « as-tu activé le MFA ? » mais « ton second facteur résiste-t-il au hameçonnage ? ». Entre un OTP recopiable et une clé FIDO2, l'écart de protection est considérable.

L'attaque par MFA fatigue

Le second facteur le plus confortable, la notification push, porte en lui une faille qui n'est pas technique mais humaine. Retour au sas.

Imaginons que le vigile derrière sa vitre reçoive, sur son écran, une demande d'accès à valider chaque fois qu'un employé présente son badge. Un attaquant a récupéré le badge de Camille mais pas son code. Il déclenche alors des demandes d'accès en rafale, dix, vingt, trente fois. Le vigile, harcelé, finit par cliquer « Autoriser » pour faire cesser le flot, ou parce qu'un complice l'appelle en se faisant passer pour le service de maintenance : « ignore l'alerte, c'est un test, valide pour qu'on débloque ça ». Par lassitude ou par confiance mal placée, la porte s'ouvre.

C'est exactement le mécanisme de la MFA fatigue, aussi appelée push bombing ou push fatigue. L'attaquant détient déjà le premier facteur (un mot de passe volé) et bombarde la victime de notifications d'approbation jusqu'à ce qu'elle cède, souvent en y ajoutant une couche d'ingénierie sociale.

L'agence américaine de cybersécurité, la CISA, documente précisément cette technique et recommande de passer à un MFA résistant au hameçonnage pour la neutraliser. Le point clé : ici, le MFA était bien activé. Il a quand même cédé, parce que la validation reposait sur un geste humain manipulable.

Le cas Uber, septembre 2022

L'illustration réelle la plus nette est la compromission d'Uber en septembre 2022. D'après la note de sécurité publiée par Uber, l'attaquant a d'abord obtenu les identifiants d'un compte d'un prestataire externe, probablement issus d'une fuite. Ces identifiants étaient protégés par MFA, ce qui aurait dû suffire.

L'attaquant a alors lancé des demandes d'approbation MFA répétées vers la cible. Comme rien ne se passait, il a contacté la personne sur une messagerie en se faisant passer pour le support informatique d'Uber, l'invitant à accepter la notification pour mettre fin aux alertes. La victime a fini par approuver. L'accès initial était obtenu, et l'attaquant a pu progresser dans le système d'information.

Le MFA d'Uber n'a pas été « cassé » techniquement. Il a été contourné par la combinaison d'un facteur volé, d'un harcèlement de notifications et d'une usurpation du support. Un second facteur résistant au hameçonnage n'aurait laissé aucune prise à cette manœuvre.

C'est la leçon centrale du billet : un MFA reposant sur l'approbation manuelle protège contre l'attaquant distant lambda, mais pas contre une campagne ciblée qui exploite la fatigue et la confiance. La résistance au hameçonnage n'est pas un détail de configuration, c'est ce qui distingue un MFA solide d'un MFA décoratif.

Le MFA résistant au phishing

La réponse, recommandée aussi bien par le NIST que par la CISA et la FIDO Alliance, consiste à choisir un second facteur qui ne peut pas être recopié ni approuvé par erreur sur le mauvais site. C'est le rôle de FIDO2, de WebAuthn et des passkeys.

Le principe, transposé au sas : au lieu d'un badge magnétique et d'un geste d'approbation, on remet à Camille une clé électronique qui dialogue directement avec la serrure de cette porte précise. Si un attaquant l'attire vers une fausse porte (un faux portail), la clé refuse de répondre parce que la serrure ne correspond pas. Il n'y a aucun code à dicter, aucune notification à valider à l'aveugle, donc rien à harceler ni à intercepter.

Techniquement, l'appareil détient une clé privée qui ne quitte jamais le matériel. Lors de la connexion, il signe un défi envoyé par le service, et cette signature est liée au domaine exact (origin binding). Un faux site présente un autre domaine, la signature ne correspond pas, l'authentification échoue d'elle-même. Le secret n'est jamais exposé, donc il n'y a rien à hameçonner.

sequenceDiagram participant U as "Utilisateur (clé/passkey)" participant N as "Navigateur" participant S as "Service légitime" S->>N: "Défi à signer (lié au domaine)" N->>U: "Demande de signature locale" U->>U: "Vérifie le domaine, signe avec la clé privée" U->>N: "Signature liée au domaine" N->>S: "Preuve renvoyée" S->>S: "Vérifie la signature et le domaine" S->>N: "Accès accordé"

Le détail qui change tout : sur un faux site, le domaine présenté ne correspond pas à celui attendu, l'appareil refuse de signer, et l'attaque s'arrête avant même de commencer. C'est cette propriété, et non la simple présence d'un second facteur, qui mérite l'étiquette « résistant au phishing ».

Passer du push à FIDO2 ne complique pas la vie de l'utilisateur, au contraire : une passkey déverrouillée par empreinte ou par visage est souvent plus rapide qu'un code à recopier. La sécurité forte et la simplicité d'usage ne sont pas en opposition ici.

Le SSO : une identité, plusieurs services

Reste un problème de confort, qui devient vite un problème de sécurité. Aux Arcades, un employé polyvalent doit parfois accéder à la bijouterie, à la réserve centrale et au bureau administratif. Lui demander de se réauthentifier complètement à chaque porte, avec badge, code et empreinte à chaque fois, le pousserait à contourner le système : porte calée, code partagé, badge prêté.

La solution est une conciergerie de confiance centrale. L'employé prouve son identité une seule fois, le matin, auprès de cette conciergerie. Elle lui remet alors un laissez-passer signé. Devant chaque boutique, il présente ce laissez-passer ; la boutique fait confiance à la signature de la conciergerie et ouvre sans tout revérifier. C'est le Single Sign-On (SSO) : une authentification, plusieurs accès.

En informatique, cette conciergerie s'appelle le fournisseur d'identité (Identity Provider, IdP). Les services qui lui font confiance sont les fournisseurs de service. Deux grands standards organisent ce dialogue :

  • SAML (Security Assertion Markup Language) : standard historique basé sur XML, très présent en entreprise pour le SSO entre applications internes.
  • OpenID Connect (OIDC) : couche d'identité bâtie au-dessus d'OAuth 2.0, plus récente, omniprésente sur le web et le mobile (c'est elle derrière les boutons « se connecter avec… »).

Le schéma résume le flux SSO, du premier accès jusqu'à l'ouverture d'un second service sans nouvelle authentification.

flowchart LR U["Utilisateur"] -->|"1 - accède"| S1["Service A"] S1 -->|"2 - redirige (pas de session)"| IDP["Fournisseur d'identité"] U -->|"3 - prouve son identité (MFA)"| IDP IDP -->|"4 - jeton signé"| U U -->|"5 - présente le jeton"| S1 U -->|"6 - accède au Service B"| S2["Service B"] S2 -->|"7 - jeton déjà valide, pas de reconnexion"| U classDef idp fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef svc fill:#ede9e1,stroke:#b5651d,color:#1a1a1a; classDef user fill:#2c3338,stroke:#1f2428,color:#f5f2ec; class IDP idp; class S1,S2 svc; class U user;

Le SSO apporte un gain réel : moins de mots de passe à gérer, donc moins de réutilisation et de post-its, une expérience fluide, et un endroit unique où appliquer une politique forte. C'est d'ailleurs le bon endroit où exiger un MFA résistant au hameçonnage, une fois pour toutes.

Le SSO concentre la sécurité au lieu de la diluer. La contrepartie est qu'il concentre aussi le risque : la conciergerie devient un point unique de défaillance.

Ce compromis se gère, il ne s'ignore pas. Si le laissez-passer central est volé ou si la conciergerie est compromise, toutes les boutiques tombent d'un coup. C'est précisément pourquoi l'authentification auprès de l'IdP doit être la plus solide du système, avec un facteur résistant au hameçonnage, et pourquoi cette logique rejoint le Zero Trust : on ne fait jamais confiance à un jeton de façon permanente, on vérifie sa validité et son contexte à chaque accès sensible. Le confort du SSO ne dispense pas de la rigueur sur la porte d'entrée.

Points clés

  • Authentification (qui es-tu) et autorisation (qu'as-tu le droit de faire) sont deux étapes distinctes. On n'autorise correctement qu'une identité d'abord prouvée.
  • Il n'existe que trois familles de facteurs : ce qu'on sait, ce qu'on possède, ce qu'on est. Le MFA exige au moins deux familles différentes ; deux mots de passe ne comptent que pour une.
  • Tout MFA ne se vaut pas. Du plus faible au plus fort : SMS OTP, TOTP, notification push, puis FIDO2 / WebAuthn. Seul ce dernier résiste au hameçonnage par construction.
  • La MFA fatigue contourne un MFA pourtant activé en harcelant la victime de demandes d'approbation, comme lors de la compromission d'Uber en septembre 2022. Un facteur résistant au phishing l'aurait neutralisée.
  • Le SSO offre une identité unique pour plusieurs services (SAML, OpenID Connect). Il concentre la sécurité, mais aussi le risque : la porte d'entrée de l'IdP doit être la mieux protégée.

Dans la série

Palier 2 : Verrouiller les accès. Domaine : Identité & accès.

Pour aller plus loin