Authentification Multifacteur : Anatomie souveraine Explorez les fondements de l’authentification numérique à travers une typologie rigoureuse — de 0FA à MFA — pour comprendre les enjeux de souveraineté, de sécurité et de résilience face aux menaces modernes.
Résumé express — Authentification Multifacteur de 0FA à MFA
Tu entres ton identifiant. Tu ajoutes un mot de passe. L’écran s’ouvre. Tu crois avoir franchi une barrière de sécurité, mais aucun facteur n’a vraiment été vérifié. C’est le royaume du 0FA — une authentification sans facteur, exposée aux attaques les plus triviales. À l’autre bout du spectre, on t’annonce le MFA comme une forteresse. Mais si les facteurs sont injectés dans le DOM, synchronisés dans le cloud ou répétés dans la même catégorie, cette forteresse est en carton. Entre ces extrêmes, 1FA et 2FA tracent des lignes de défense fragiles ou minimales. Cette chronique requalifie chaque méthode selon sa véritable anatomie, en intégrant les angles morts laissés par les référentiels classiques (CNIL, NIST, ENISA).
🚨 Message direct : Tant que vos secrets résident dans le navigateur, vous êtes en 0FA déguisé. Le seul chemin vers la souveraineté passe par des flux Zero-DOM matériels (NFC, HSM, sandbox hors-OS).

Paramètre de lecture
Temps de lecture résumé express : ≈ 3 minutes
Temps de lecture résumé avancé : ≈ 5 minutes
Temps de lecture complet : ≈ 31 minutes
Date de mise à jour : 2025-09-26
Niveau de complexité : Avancé / Expert
Densité technique : ≈ 72 % Langues : CAT · EN · ES · FR
Spécificité linguistique : Lexique souverain — densité technique élevée
Accessibilité : Optimisé lecteurs d’écran — ancres sémantiques incluses
Type éditorial : Chronique stratégique — Digital Security — (Cyberculture)
À propos de l’auteur : Jacques Gascuel, inventeur et fondateur de Freemindtronic®, spécialiste de la cybersécurité embarquée et pionnier de solutions souveraines basées sur le NFC, le Zero-DOM et le chiffrement matériel. Ses travaux portent sur la protection des données sensibles et l’authentification multifacteur sans dépendance cloud.
Points clés
- 0FA : identifiant + mot de passe ≠ facteur → aucune barrière réelle.
- 1FA : un seul facteur (souvent le mot de passe) → vulnérable au phishing, au DOM et au cloud.
- 2FA : le rempart minimal → deux facteurs distincts, résistance moyenne si séparation réelle.
- MFA : forteresse adaptative → robuste seulement si les facteurs sont indépendants et hors-DOM.
- Identifiant privé avancé : peut devenir un facteur de possession uniquement s’il est attribué, non devinable, et vérifié hors-DOM.
- DEF CON 33 : a démontré l’exfiltration invisible de mots de passe, TOTP et passkeys synchronisés.
- Zero-DOM : la seule voie souveraine — NFC, HSM, sandbox matérielle, hors navigateur et hors cloud.
Résumé avancé — Anatomie Zero-DOM pour l’Authentification Multifacteur
Depuis deux décennies, les institutions (CNIL, NIST, ENISA) décrivent l’authentification comme une juxtaposition de facteurs. Mais cette lecture oublie deux réalités structurelles : 0FA (authentification sans facteur) et 1FA (authentification monofactorielle), pourtant omniprésentes dans les usages. Un identifiant seul ne prouve rien ; un mot de passe injecté dans le DOM n’est pas un facteur ; un MFA basé sur des secrets synchronisés reste vulnérable aux exfiltrations invisibles.
• Vérifiable indépendamment
• Attribué exclusivement
• Non devinable
• Hors DOM, hors OS, hors cloud
Pourquoi c’est critique
- 0FA se cache derrière la majorité des accès courants : identifiant + mot de passe.
- 1FA n’apporte qu’une barrière symbolique, vulnérable au phishing et aux injections locales.
- 2FA devient robuste uniquement si les facteurs sont réellement indépendants (pin code + mot de passe, par ex.).
- MFA n’est pas synonyme de forteresse : mal segmentée, elle se réduit à une illusion de sécurité.
Leviers souverains
L’authentification forte repose sur une architecture Zero-DOM : garder les secrets hors du navigateur, valider localement via HSM ou NFC, et démontrer l’attribution exclusive. C’est le seul moyen de rendre les FA auditables et durables, dans un cadre Zero Trust ou SecNumCloud.
En cybersécurité souveraine ↑ Cette chronique appartient à la rubrique Digital Security, tournée vers les exploits, vulnérabilités systémiques et contre-mesures matérielles zero-trust, tout en s’inscrivant également dans la sphère Cyberculture, qui analyse les impacts sociotechniques et culturels des choix en authentification et en souveraineté numérique.
Définitions des facteurs (FA) pour l’Authentification Multifacteur
Définition formelle pour une Authentification Multifacteur fiable
Un facteur d’authentification est une donnée ou un mécanisme vérifiable, non devinable, non réutilisable, attribué de manière exclusive, permettant de prouver la possession, la connaissance ou l’inhérence d’un utilisateur.
• Vérifiable indépendamment d’un tiers non souverain
• Non injecté dans un environnement exposé (DOM, OS, cloud)
• Attribué ou généré de manière exclusive
• Non synchronisé sans contrôle local
Typologie des facteurs classiques au service de l’Authentification Multifacteur
- Connaissance : ce que je sais (mot de passe, PIN).
- Possession : ce que je possède (carte NFC, token matériel, identifiant privé avancé).
- Inhérence : ce que je suis (biométrie, empreinte digitale, iris).
Quand un identifiant devient-il un facteur en Authentification Multifacteur ?
La confusion est fréquente : un identifiant (email, ID client) n’est pas un facteur.
Il peut le devenir seulement s’il respecte des conditions strictes d’attribution et de vérification.
- Un identifiant public (email, pseudo) reste un simple adressage.
- Un identifiant privé standard (matricule interne, ID client) est trop exposé pour constituer un facteur.
- Un identifiant privé avancé, attribué par un tiers de confiance, non devinable et vérifié hors DOM (ex. : NFC injecté via HSM), peut être reconnu comme facteur de possession.
Exemple souverain
Un identifiant NFC généré aléatoirement, injecté hors navigateur et validé par un HSM, devient un facteur de possession.
S’il est combiné à un mot de passe (facteur de connaissance), l’authentification est alors un 2FA, même sans OTP ni biométrie.
• Un identifiant stocké dans le DOM ≠ facteur
• Un identifiant complexe mais devinable (numéro de série, matricule client) ≠ facteur
Typologies 0FA → MFA de l’Authentification Multifacteur
Chaque méthode d’authentification est présentée comme une barrière, mais leur solidité réelle dépend des critères ignorés par les référentiels institutionnels. Reprenons la séquence : 0FA, 1FA, 2FA et MFA. Chacune a une anatomie, une surface d’exposition et un niveau de souveraineté.
0FA — limites et risques pour l’Authentification Multifacteur
Définition : une authentification où aucun facteur vérifié n’est engagé, même si un identifiant et un mot de passe sont saisis.
Risques critiques :
- Phishing trivial (un email + mot de passe suffisent)
- Credential stuffing à grande échelle
- Brute force sans frein structurel
- Exposition directe au DOM et au cloud
1FA — rôle minimal et exposition dans l’Authentification Multifacteur
Définition : une authentification reposant sur un seul facteur, généralement un mot de passe (connaissance).
Exemple : segmentation UX avec identifiant + mot de passe, mais vérifiés dans le même flux.
Risques :
- Injection DOM (le mot de passe est manipulable dans le navigateur)
- Dépendance au cloud (sauvegardes, synchronisation)
- Usurpation via hameçonnage ou re-jeu
2FA — rempart minimal de l’Authentification Multifacteur
Définition : deux facteurs distincts parmi connaissance, possession, inhérence.
Exemples : mot de passe + SMS, mot de passe + app OTP, identifiant privé avancé + mot de passe.
Avantages :
- Évite l’usurpation par mot de passe seul
- Introduit une séparation logique entre facteurs
Limites :
- Second facteur phishable (OTP, push, SMS)
- Dépendance au DOM si injection via navigateur
- Cloud = surface d’attaque supplémentaire
MFA — forteresse conditionnelle de l’Authentification Multifacteur
Définition : combinaison de plusieurs facteurs distincts, souvent enrichis de signaux contextuels (localisation, heure, comportement).
Avantages :
- Résistance accrue aux attaques ciblées
- Compatibilité avec Zero Trust et architectures décentralisées
Limites :
- Complexité UX → fatigue ou erreurs
- « Faux MFA » : facteurs de même catégorie ou synchronisés
- Dépendance critique si les secrets passent par le DOM ou le cloud
Typologie des OTP — tous les mécanismes, tous les risques
Les « OTP » (One Time Passwords) forment une famille hétérogène : SMS, e-mail, TOTP/HOTP, OTP matériel (OATH), OTP push, et variantes propriétaires. Ils partagent l’objectif d’ajouter un facteur de possession ou d’usage unique, mais leurs propriétés de sécurité et leur compatibilité avec une doctrine Zero-DOM divergent fortement.
Type d’OTP | Exemples / mécanisme | Vulnérabilités principales | Statut souverain / recommandation |
---|---|---|---|
SMS OTP | Code envoyé par SMS (réseau téléphonique) | SIM swap, interception opérateur, phishing (EvilProxy) | ❌ Déconseillé pour accès sensibles — pas souverain |
Email OTP | Code envoyé par message électronique | Compromission boîte mail, interception, phishing | ⚠️ Usage faible — acceptable pour low-risk, pas souverain |
TOTP (Time-based) | Algorithme OATH TOTP (ex. Google Authenticator) — code local, durée courte | Phishing temps-réel (EvilProxy), synchronisation imprudente, exportabilité | ✅ Acceptable si provisionné/stocké hors-DOM et lié au device (HSM/NFC) |
HOTP (Counter-based) | OATH HOTP — code basé sur compteur (tokens matériels) | Vol physique du token, clonage matériel si pas maîtrisé | ✅ Souverain si token matériel géré localement (PKI/HSM) |
Hardware OTP (OATH tokens) | Token physique (display) ou clé matérielle délivrant OTP | Perte/vol du token, provisioning non sécurisé | ✅ Recommandé pour environnements souverains (provisionnement hors-DOM) |
Push OTP / Push MFA | Notification push vers device ; validation via app (souvent cloud-relay) | MFA fatigue, push-bombing, confirmation accidentelle, relay/cloud compromise | ⚠️ Acceptable si binding appareil + attestation matérielle |
Passkeys / WebAuthn (synchronisées) | Clés publiques liées à devices ; parfois synchronisées via cloud (ex. passkeys navigateur) | Overlay phishing sur UI synchronisée, synchronisation cloud = compromission | ✅⚠️ Sûres si non synchronisées et stockées dans HSM/local authenticator (Zero-DOM) |
OTP propriétaires (vendor-specific) | Solutions fermées (ex. SMS relay, vendor SDKs) | Dépendance fournisseur, synchronisation non maîtrisée, backdoors | ⚠️ Évaluer cas par cas ; préférence pour standards ouverts et contrôle local |
Principes de sécurité et recommandations pratiques
- Éviter SMS et email pour accès à privilèges — trop d’attaques SIM/compromission boîte.
- Préférer OTP matériel (HOTP/OATH token, clé matérielle) provisionnés hors-DOM via HSM/PKI.
- TOTP reste utile si la seed est provisionnée et conservée hors DOM (ex. HSM) et si l’UX force binding local.
- Push MFA doit inclure binding cryptographique de l’appareil, attestation et protection contre le push-bombing.
- Passkeys/WebAuthn : éviter la synchronisation cloud ou exiger attestation locale (authenticator attestation) et UX anti-overlay.
- TLS, anti-replay, expirations courtes, nonces et journaux d’usage : appliquer systématiquement.
- Désactiver l’autofill pour champs OTP sensibles ; ne pas stocker de seeds dans localStorage/DOM.
Impact sur la typologie FA
- Un OTP synchronisé perd l’exclusivité et tend vers non-facteur.
- Les OTP matériels provisionnés hors-DOM peuvent constituer un facteur de possession valide (→ 2FA/MFA souveraine).
- Les OTP basés réseau (SMS) affaiblissent la classification : 2FA via SMS ≠ 2FA souveraine.
Note : ces recommandations doivent être appliquées en regard des exigences réglementaires (RGPD, NIS2, SecNumCloud) et des contraintes d’usage. Le compromis sécurité/UX doit pencher fortement vers la sécurité pour comptes à privilèges.
Attaques connues contre l’Authentification Multifacteur
La valeur d’une authentification ne se juge pas uniquement par son design, mais par la résistance observée face aux attaques. Voici une typologie des menaces documentées dans les référentiels OWASP, confirmées par les démonstrations DEF CON 33 et les retours de terrain.
Vecteur | Type d’attaque | Description | Source vérifiable |
---|---|---|---|
Réseau | Rejeu de session | Réutilisation d’un cookie ou jeton intercepté via proxy, MITM ou vol de jeton. | Vaadata — MFA et détournement de session |
Navigateur | Clickjacking DOM | Exfiltration invisible via iframe et focus() — mots de passe, OTP, passkeys, TOTP. | Freemindtronic — DEF CON 33 |
Cloud | Compromission OAuth / jetons | Réutilisation de jetons OAuth valides ou détournés — contournement des mécanismes MFA liés au cloud. | KeeperSecurity — Jetons persistants / compromission OAuth |
OS local | Contournement hors session | Accès via WinRE, clé USB, modification du registre — récupération ou réinitialisation d’OTP/clefs stockées localement. | BitUnlocker — DEF CON 33 |
Téléphonie | SIM swapping | Détournement du numéro pour intercepter les SMS OTP ou réceptionner les push. | Akonis — MFA et phishing |
Push cloud | Push-bombing / MFA fatigue | Spam de notifications push jusqu’à acceptation involontaire ou erreur humaine. | Akonis — MFA fatigue |
WebAuthn / Passkeys | Overlay phishing / WebAuthn hijack | Faux écran de confirmation ou overlay qui abuse des passkeys synchronisées (UI spoofing). | Freemindtronic — DEF CON 33 / WebAuthn hijacking |
OTP interception / compromission | Accès à la boîte mail pour capturer les OTP envoyés ou réinitialiser des comptes. | OneLogin — MFA par email compromise | |
Social | Spear phishing | Usurpation ciblée via email, faux portails ou interfaces dédiées — récupération de credentials et facteurs. | OneLogin — Attaques contre MFA |
⮞ Synthèse :
Chaque vecteur cible une faiblesse structurelle : le DOM, le cloud, le réseau, la couche OS ou l’interface utilisateur. Les OTP, passkeys et jetons OAuth sont vulnérables dès qu’ils sont injectés dans un environnement exposé. La souveraineté ne consiste pas à multiplier les facteurs, mais à changer l’environnement d’injection, de vérification et de stockage.
Environnements d’injection — DOM, cloud, OS, Zero-DOM dans l’Authentification Multifacteur
Environnements d’injection — DOM, cloud, OS, Zero-DOM
La robustesse d’un facteur ne dépend pas seulement de sa nature (connaissance, possession, inhérence). Elle dépend aussi de l’environnement où il est injecté, stocké ou validé. Un même facteur peut être souverain ou vulnérable selon qu’il transite par le navigateur, le cloud, l’OS ou un module matériel hors-OS.
Environnement | Exemples | Niveau de vulnérabilité | Facteur reconnu ? |
---|---|---|---|
DOM (navigateur) | Formulaire HTML, passkey synchronisée, autofill | Très élevé | ❌ Non — exfiltrable |
Cloud (serveur tiers) | OAuth token, push MFA, synchronisation identifiant | Élevé | ⚠️ Partiel — dépend du fournisseur |
OS local | Session Windows, registre, TSE, macOS keychain | Moyen | ⚠️ Oui si isolé — vulnérable hors session |
Zero-DOM / Hors-OS | Carte NFC, HSM, sandbox matérielle, smartcard | Faible à nul | ✅ Oui — facteur souverain |
Un facteur n’est facteur que s’il est validé hors DOM et hors synchronisation.
Mini-correspondance attaque → environnement :
- Clickjacking DOM → casse 1FA/2FA/MFA injectés côté navigateur.
- SIM swap → casse 2FA basé sur SMS cloud.
- Rejeu OAuth → exploite les jetons MFA stockés côté cloud.
- Accès WinRE → contourne 1FA/2FA stockés dans l’OS local.
Empreinte navigateur (browser fingerprinting) — facteur passif à utiliser avec prudence
La thèse de l’Université de Rennes 1 (2020) montre que le browser fingerprinting, exploité à grande échelle et avec un jeu d’attributs riche (216 attributs initiaux, 46 dérivés, 4,145,408 empreintes analysées), peut atteindre une distinguabilité et une stabilité élevées : simulation d’un comparateur simple donne un taux d’erreur compris entre 0,61 % et 4,30 % selon les populations. Autrement dit, l’empreinte navigateur peut fournir un signal supplémentaire d’authenticité sans friction utilisateur.
Toutefois, ce signal n’est pas équivalent à un facteur de possession souverain : il reste probabiliste, dépend fortement du choix et de la stabilité des attributs, et peut être contourné ou altéré par des stratégies d’évasion. Utiliser le fingerprinting comme facteur unique serait donc imprudent ; en revanche, c’est un bon indicateur complémentaire pour l’analyse de risque (détection d’anomalies, renforcement adaptatif) si et seulement si il est combiné à des preuves hors-DOM (HSM, clés matérielles, attestations).
Implications pratiques :
- Usage conseillé : fingerprinting = signal de risque / signal d’alerte, jamais facteur unique pour accès sensibles.
- Combinaison : utiliser pour déclencher durcissements adaptatifs (ex. exiger HSM, challenge hors-DOM, step-up auth) plutôt que pour autoriser l’accès seul.
- Sélection d’attributs : appliquer la méthode de sélection (stabilité vs coût de collecte) ; éviter attributs instables ou facilement modifiables par user agent spoofing.
Limites & risques :
- Signal probabiliste — taux d’erreur observé 0,61–4,30% selon populations ; suficientes pour alerte, insuffisant pour preuve d’identité.
- Vie privée & RGPD — suivi / profilage : nécessité d’évaluer base légale, minimisation des données et durée de conservation.
- Évasion & contrefaçon — attaquant capable de générer empreintes falsifiées peut réduire l’efficacité ; surveillance continue requise.
Synchronisation des facteurs — impact sur l’Authentification Multifacteur
Synchronisation des facteurs — confort UX ou faille structurelle ?
La synchronisation est souvent présentée comme un atout UX : vos passkeys, OTP ou jetons OAuth sont disponibles partout, sur tous vos appareils. En réalité, elle constitue une faille systémique, car elle centralise les secrets et les expose aux mêmes vecteurs d’attaque que le DOM ou le cloud.
Élément synchronisé | Risque principal | Exemple d’attaque |
---|---|---|
Passkeys | Overlay phishing | DEF CON 33 — détournement via superposition d’UI |
OTP | Rejeu ou interception | SIM swap, EvilProxy |
Jetons OAuth | Réutilisation, détournement | Compromission Google OAuth2 |
Doctrine souveraine :
- Tout facteur synchronisé perd son exclusivité → il n’est plus un facteur.
- La souveraineté exige des facteurs vérifiés localement, injectés hors DOM et hors cloud.
- La CNIL recommande explicitement de limiter la synchronisation et de privilégier les vérifications locales/matérielles.
Résistance par méthode dans l’Authentification Multifacteur
Pour juger de la valeur d’un FA, il faut noter sa résistance face aux attaques observées. Le tableau ci-dessous cartographie les attaques courantes, les FA qu’elles compromettent typiquement, et les contre-mesures architecturales (Zero-DOM / HSM / binding) à privilégier.
Attaque | Environnement visé | FA vulnérable | Contre-mesure (Zero-DOM / souveraine) |
---|---|---|---|
Clickjacking DOM / overlay phishing | Navigateur / DOM | 1FA ; 2FA/MFA si second facteur injecté dans le DOM (TOTP, passkey sync) | Ne pas mettre de secrets dans le DOM ; déplacer vérif. vers HSM/NFC ou sandbox hors-navigateur ; UX anti-overlay. |
EvilProxy / phishing temps-réel | Web / proxy d’attaque | TOTP, passkeys synchronisées, push MFA non bindés | Binding cryptographique device↔service ; attestation d’authenticator ; vérification hors-flux via HSM. |
SIM swapping | Réseau mobile | 2FA SMS | Interdire SMS pour accès sensibles ; préférer OTP matériel / clé physique / NFC/HSM. |
Compromission OAuth / replay token | Cloud / serveur tiers | MFA dépendant de jetons cloud (push, SSO tokens) | Jetons courts ; liaison appareil (device binding) ; vérification locale/mutualisée ; rotation forcée. |
Accès hors-session (WinRE, clé USB) | OS local | Secrets stockés OS (keychains, registres), 1FA/2FA locaux | Chiffrement matériel des clés ; stockage dans HSM ; verrouillage disque avec attestation matérielle. |
Push-bombing / MFA fatigue | Push cloud → mobile | Push MFA (app) sans binding | Exiger preuve d’intention forte (PIN local, biométrie) ; limiter tentatives ; binding certifié. |
Provisioning / supply-chain compromise | Fournisseur / device | Tokens matériels mal provisionnés, seeds TOTP exposés | Provisionnement hors-ligne / HSM PKI ; audits supply-chain ; attestation d’origine matérielle. |
⮞ Lecture rapide :
- Si un facteur traverse le DOM ou une synchronisation cloud, considérez-le comme non fiable.
- Les contremesures efficaces sont architecturales : HSM/NFC, device binding, attestation, provisioning hors-DOM.
- Ne confondez pas nombre de facteurs et indépendance des facteurs : c’est cette indépendance — et son environnement — qui crée la robustesse.
Architectures actives vs passives en Authentification Multifacteur
Dans la lecture souveraine de l’authentification, il convient de distinguer deux approches : les architectures passives et les architectures actives. Les premières reposent sur des facteurs consommés et validés à distance — typiquement le mot de passe transmis à un serveur, ou l’OTP centralisé via un service cloud. Elles exposent l’utilisateur à des risques structurels, puisque la vérification dépend d’un tiers et d’un environnement externe. Les secondes, dites actives, impliquent une interaction matérielle locale — clé NFC, token U2F, HSM, Zero-DOM — qui réalise la validation sans dépendre d’une infrastructure distante. C’est cette logique active qui permet de bâtir une authentification réellement souveraine, résiliente aux compromissions systémiques et aux vulnérabilités inhérentes aux environnements passifs.
Lecture des signaux — faible, moyen, fort en Authentification Multifacteur
Un facteur d’authentification ne se résume pas à sa catégorie (connaissance, possession, inhérence). Il émet un signal de sécurité — faible, moyen ou fort — selon son environnement, sa vérifiabilité, et sa résistance aux attaques. Cette section cartographie les signaux observables pour chaque mécanisme, indépendamment de sa typologie déclarée.
Mécanisme | Exemple | Signal | Justification |
---|---|---|---|
Mot de passe | Saisi dans navigateur | ❌ Faible | Injectable, phishable, réutilisable, aucun ancrage matériel |
OTP par SMS | Code reçu via réseau mobile | ⚠️ Moyen | Interceptable (SIM swap), dépendance opérateur, faible exclusivité |
TOTP local | Google Authenticator hors DOM | ✅ Fort | Non transmissible, exclusif à l’appareil, validé hors DOM |
Push MFA | Notification vers app cloud | ⚠️ Moyen | Vulnérable au push-bombing et à l’acceptation involontaire ; dépend cloud |
Token matériel | Clé physique avec OTP ou signature | ✅ Fort | Attribution exclusive, preuve locale, auditabilité forte |
Passkey synchronisée | WebAuthn via cloud | ❌ Faible | Perte d’exclusivité, overlay phishing, dépendance fournisseur |
Biométrie locale | Empreinte liée à device avec enclave sécurisée | ✅ Fort | Non transmissible, vérifiée matériellement, usage exclusif |
Identifiant seul | Email ou ID client | ❌ Aucun signal | Déclaratif, non vérifié, non exclusif, simple adressage |
Lecture typologique :
- Un signal fort implique une vérification hors DOM, hors cloud, avec preuve locale ou matérielle.
- Un signal moyen peut être toléré pour des usages non-critiques, mais reste vulnérable si la chaîne d’attribution n’est pas exclusive.
- Un signal faible ou nul ne doit jamais être considéré comme un facteur souverain, même s’il est classé comme « MFA ».
Un facteur est reconnu comme authentifiant seulement s’il satisfait trois dimensions cumulatives :
- Cryptographique : non-devinable, non-réutilisable, non-transmissible.
- Attribution : exclusif, vérifié, auditable.
- Environnement : validé hors DOM/cloud, idéalement matériel (HSM, NFC, enclave sécurisée).
Sans cette triple exigence, un mécanisme reste un signal faible, quel que soit son label institutionnel (1FA, 2FA, MFA).
Tableau doctrinal — Validation des critères
Mécanisme | Cryptographique | Attribution | Environnement | Statut final |
---|---|---|---|---|
Mot de passe (navigateur) | ❌ | ❌ | ❌ | ❌ Signal faible |
OTP SMS | ⚠️ | ❌ | ❌ | ⚠️ Signal moyen |
TOTP local (hors DOM) | ✅ | ⚠️ | ✅ | ✅ Signal fort |
Token matériel (HSM/NFC) | ✅ | ✅ | ✅ | ✅ Signal fort |
Passkey synchronisée (cloud) | ✅ | ❌ | ❌ | ❌ Signal faible |
Biométrie locale (enclave sécurisée) | ✅ | ✅ | ✅ | ✅ Signal fort |
Auditabilité & traçabilité des facteurs en Authentification Multifacteur
Un facteur n’est souverain que s’il est traçable et auditable. L’auditabilité permet de prouver qu’un facteur a bien été présenté par l’utilisateur légitime, au moment attendu, via un canal exclusif. Sans journal, sans horodatage, ou sans attestation matérielle, un facteur peut être utilisé mais ne laisse aucune preuve exploitable en cas d’incident.
Facteur | Auditabilité native | Exemple de traçabilité | Limites / risques |
---|---|---|---|
Mot de passe | ❌ Faible | Log tentative + hash comparé | Réutilisation invisible, aucune preuve de possession |
OTP SMS | ⚠️ Moyen | Logs opérateur + serveur d’authentification | Pas de preuve d’attribution exclusive (SIM swap) |
OTP email | ⚠️ Moyen | Journal SMTP / réception utilisateur | Compromission de boîte non détectable |
TOTP/HOTP | ✅ Fort | Horodatage + seed connu serveur ; validation horloge/counter | Phishing temps-réel = difficilement traçable |
Token matériel (HSM, NFC, smartcard) | ✅ Très fort | Attestation matérielle, horodatage sécurisé, preuve cryptographique | Perte/vol du token → réattribution nécessaire |
Push MFA | ⚠️ Moyen | Logs serveur + interaction utilisateur | Push-bombing : log présent mais non preuve d’intention |
Passkeys locales (WebAuthn + authenticator) | ✅ Fort | Attestation cryptographique, journal côté serveur | Fortement dépendant de la gestion cloud si synchronisée |
Biométrie | ⚠️ Variable | Log d’usage du capteur, preuve de succès/échec | Aucune donnée biométrique ne doit être exportée → audit indirect uniquement |
Identifiant privé avancé (HSM/NFC) | ✅ Fort | Attestation exclusive, log matériel + serveur | Souverain seulement si non exposé DOM/cloud |
Principes stratégiques :
- Un facteur est auditable seulement si l’événement est horodaté, signé ou lié à un device attesté.
- Les OTP réseau (SMS/email) génèrent des journaux, mais ne prouvent pas l’attribution au bon utilisateur.
- Les solutions souveraines reposent sur des preuves cryptographiques locales (HSM, NFC, smartcards, passkeys locales).
- L’auditabilité est un critère central du RGPD/NIS2 : sans logs fiables, impossible d’assurer accountability.
Note : L’auditabilité n’est pas qu’une exigence technique : c’est aussi un levier juridique et réglementaire. Elle conditionne la preuve légale d’authentification en cas d’incident ou de litige.
Faux MFA — erreurs et contournements en Authentification Multifacteur
Tous les MFA ne se valent pas. Un MFA mal conçu peut donner l’illusion de sécurité tout en restant vulnérable à des attaques triviales. La souveraineté impose d’identifier ces faux MFA : des combinaisons de facteurs qui paraissent multiples mais qui, en réalité, ne créent pas de séparation de confiance ni de robustesse structurelle.
Scénario | Pourquoi c’est un faux MFA | Conséquence | Correctif souverain |
---|---|---|---|
Mot de passe + OTP SMS | Deux facteurs sur le même canal réseau → SMS vulnérable (SIM swap, interception opérateur) | Un simple SIM swap casse l’accès | Remplacer OTP SMS par token matériel / OTP hors-DOM |
Mot de passe + email OTP | Même canal logique (identifiants + OTP stockés dans boîte mail) | Compromission boîte mail = accès total | OTP hors mail (TOTP/HOTP matériel) |
Passkey synchronisée + mot de passe | Facteurs stockés et synchronisés via cloud → perte d’exclusivité | Overlay phishing possible, compromission cloud = MFA brisé | Passkey locale non synchronisée (authenticator matériel) |
2 OTP sur même canal | Ex. : deux codes envoyés par SMS ou deux OTP via email | Pas de séparation de canal → un seul vecteur d’attaque | Diversifier les canaux (token + mot de passe, OTP matériel + biométrie) |
Biométrie mobile + push cloud | Les deux facteurs transitent via l’OS et le cloud du constructeur | Compromission device/OS → MFA contourné | Biométrie locale validée matériellement + HSM/NFC |
SSO cloud + push MFA cloud | Dépendance unique au fournisseur cloud ; aucun contrôle local | Un détournement OAuth ou compromission serveur = accès total | Introduire un facteur souverain hors-cloud (HSM, smartcard) |
Principes de vigilance :
- Deux éléments sur le même canal ou le même environnement = pas un vrai MFA.
- Les facteurs synchronisés (cloud, navigateur) perdent leur indépendance.
- Un MFA ne vaut que si chaque facteur repose sur une surface d’attaque distincte et hors DOM/OS exposé.
Note : Beaucoup d’organisations communiquent sur le MFA comme argument marketing. La question n’est pas « avez-vous du MFA ? » mais « vos facteurs sont-ils réellement indépendants et auditables ? ».
Souveraineté typologique — doctrine pour l’Authentification Multifacteur
Souveraineté typologique — critères et doctrine
La véritable robustesse d’une authentification ne se mesure pas au nombre de facteurs, mais à leur indépendance, leur environnement d’injection et leur contrôle souverain. Une authentification est dite souveraine lorsqu’elle ne dépend ni d’un cloud tiers, ni d’un DOM exposé, ni d’un OS compromis, et qu’elle permet une preuve locale vérifiable.
Critère | Exigence souveraine | Pourquoi |
---|---|---|
Indépendance des facteurs | Chaque facteur doit reposer sur un canal et un mécanisme distincts (connaissance, possession, inhérence) | Évite le « faux MFA » où deux éléments partagent la même surface d’attaque |
Environnement hors-DOM | Les secrets ne doivent jamais transiter ni être stockés dans le DOM du navigateur | Le DOM est exfiltrable (clickjacking, injection, overlay) |
Absence de synchronisation cloud | Facteurs non copiés ni synchronisés via serveurs tiers | Évite la perte d’exclusivité et la compromission à distance |
Vérification locale | Preuve d’attribution et validation faites localement (HSM, NFC, smartcard) | Garantit l’exclusivité et l’auditabilité de l’usage |
Traçabilité et auditabilité | Capacité à journaliser et prouver l’usage de chaque facteur | Permet conformité RGPD, NIS2, SecNumCloud, ISO 27001 |
Doctrine de souveraineté :
- Zero-DOM : aucun secret ne doit résider dans le navigateur.
- Hors-cloud : limiter la dépendance aux fournisseurs externes.
- Attestation matérielle : chaque facteur doit être vérifié par une preuve cryptographique locale.
- Auditabilité : tout usage de facteur doit être journalisable et opposable.
Note : Cette doctrine dépasse les exigences actuelles (CNIL, NIST, ENISA). Elle établit un cadre applicable aux infrastructures critiques, aux administrations et aux environnements militaires ou diplomatiques.
Exigences RGPD et NIS2
L’Authentification Multifacteur n’est pas seulement un choix technique : elle répond aussi à des obligations légales européennes.
Le RGPD, notamment son article 32, impose la mise en œuvre de mesures techniques et organisationnelles appropriées pour garantir la sécurité des données personnelles.
Dans ce cadre, l’authentification forte est explicitement considérée comme une contre-mesure appropriée.
La directive NIS2, publiée au Journal officiel de l’Union européenne, élargit le champ des entités soumises à des obligations de cybersécurité et met l’accent sur l’authentification robuste et la résilience des infrastructures critiques.
À ce titre, 0FA, 1FA ou 2FA apparaissent insuffisants face aux exigences attendues.
Seul un MFA souverain, privilégiant des architectures actives et Zero-DOM, permet simultanément de réduire la dépendance au cloud et d’assurer une conformité durable.
- ✓ RGPD — Article 32 : sécurité des données personnelles
- ✓ NIS2 — Résilience et robustesse de l’authentification
- ✓ MFA souverain — Alignement technique et doctrinal
Cartographie sectorielle de l’Authentification Multifacteur
Au-delà des doctrines et des normes, il est essentiel de comprendre comment l’Authentification Multifacteur se déploie concrètement dans les différents secteurs stratégiques.
🟧 Passif → mot de passe / OTP SMS
🟨 Faible → MFA dépendant du cloud
🟩 Élevée → MFA robuste multi-facteurs
🟩 foncé Souveraine → MFA actif, Zero-DOM, clé matérielle
L’infographie compare les secteurs Banque, Santé, Énergie & Industrie, Défense & Recherche selon quatre niveaux de maturité : Passif, Faible, Élevée, Souveraine (MFA Zero-DOM).
Cette cartographie sectorielle permet de relier les exigences réglementaires (RGPD, NIS2) aux réalités opérationnelles et met en évidence les écarts de maturité selon les environnements critiques.
- RGPD – Article 32 : Sécurité du traitement
Texte officiel sur gdpr-info.eu - Directive NIS2 – Cybersécurité des secteurs critiques
Texte consolidé sur EUR-Lex - Directive DSP2 – Authentification forte dans le secteur bancaire
Directive européenne sur les services de paiement - CNIL – Recommandation officielle sur la MFA
Recommandation 2025 sur l’authentification multifacteur - Cartographie sectorielle MFA – Synthèse par secteur
Analyse sectorielle MFA : finance, santé, industrie, défense
Cette orientation illustre une prise de conscience progressive : seul un MFA souverain, libéré des dépendances cloud, peut offrir une conformité durable tout en garantissant une souveraineté numérique réelle.
En résumé, la cartographie sectorielle de l’Authentification Multifacteur révèle une adoption encore hétérogène, où coexistent des pratiques passives vulnérables et des initiatives pionnières vers des architectures actives souveraines. C’est précisément dans cette tension que s’inscrit l’analyse stratégique de cette chronique.
Preuve d’attribution — quand un identifiant devient facteur en Authentification Multifacteur
Un identifiant n’est pas automatiquement un facteur d’authentification. Pour qu’il le devienne, il doit être attribué, vérifié, et exclusif. Cette section clarifie les conditions techniques et typologiques qui permettent de considérer un élément comme un facteur de possession légitime.
Mécanisme | Exemple | Vérification | Statut typologique |
---|---|---|---|
Auto-déclaré | Email saisi par l’utilisateur | ❌ Aucun contrôle | ❌ Non facteur |
Attribué sans preuve | ID client généré par système | ⚠️ Faible — non exclusif | ❌ Non facteur |
Attribué avec preuve | OTP injecté via NFC HSM | ✅ Vérifié hors DOM | ✅ Facteur de possession |
Identifiant biométrique | Empreinte liée à un device | ✅ si attestation matérielle | ✅ si non synchronisé |
Passkey synchronisée | Clé WebAuthn partagée via cloud | ❌ Non exclusive | ⚠️ Faux facteur |
Token matériel | Clé physique liée à un identifiant unique | ✅ Attestation locale | ✅ Facteur souverain |
Critères de validité typologique
- Attribution exclusive à l’utilisateur
- Vérification hors session et hors DOM
- Stockage local ou matériel (HSM, NFC, token)
- Absence de synchronisation cloud
- Attestation cryptographique ou matérielle
Typologie des erreurs fréquentes
- Confondre identifiant et facteur (ex. : email = possession)
- Accepter un facteur synchronisé comme exclusif
- Injecter un facteur dans le DOM sans vérification
- Utiliser un identifiant non lié à une preuve matérielle
Note : la preuve d’attribution est un prérequis pour toute classification MFA souveraine. Sans elle, l’architecture repose sur des éléments déclaratifs, manipulables ou réutilisables.
Normes & doctrines — cadrage international de l’Authentification Multifacteur
Les normes et doctrines de cybersécurité définissent des exigences minimales, mais elles n’intègrent pas toutes la granularité 0FA/1FA/2FA/MFA. Leur vocabulaire reste souvent limité à « authentification forte », sans distinction entre un facteur réel ou un facteur affaibli par son environnement (DOM, cloud, synchronisation).
Norme / Cadre | Origine | Typologies reconnues | Exigence MFA | Commentaires souverains |
---|---|---|---|---|
NIST SP 800-63B | 🇺🇸 États-Unis | 1FA, 2FA, MFA | MFA recommandé pour tous les accès sensibles | Ne distingue pas 0FA ; MFA phishable si facteurs injectés dans DOM |
ISO/IEC 29115 | International | Niveaux d’assurance (LoA 1-4) | MFA requis dès LoA3 | Parle d’assurance mais pas d’environnement d’injection |
eIDAS 2.0 | 🇪🇺 Europe | Identité numérique qualifiée | MFA obligatoire pour services publics | Compatible avec identifiants privés avancés et Zero-DOM |
Zero Trust Architecture (ZTA) | 🇺🇸 CISA / NIST | MFA + vérification continue | MFA exigé en continu, pas seulement à l’entrée | Approche dynamique mais pas toujours matérialisée hors cloud |
OWASP ASVS v4.0 | Communauté | MFA + séparation des rôles | MFA obligatoire pour comptes admin et sensibles | Reconnaît la fatigue MFA, mais ne traite pas la souveraineté matérielle |
Lecture souveraine :
- Omission critique : aucun standard ne définit 0FA ou 1FA, pourtant massivement utilisés.
- Flou : les normes parlent de MFA mais ne qualifient pas l’environnement (DOM, cloud, OS).
- Ouverture : eIDAS 2.0 et ZTA permettent d’intégrer une approche Zero-DOM souveraine.
</col]
Cartographie 0FA → MFA — quelles normes couvrent quoi ?
Panorama rapide : quelles typologies sont explicitement (ou implicitement) prises en compte par les standards, et sous quelles conditions. Utile pour relier étiquettes et exigences réelles.
Typologie | NIST 800-63B | ISO/IEC 29115 | eIDAS 2.0 | ZTA (CISA/NIST) | OWASP ASVS | FIDO2 / WebAuthn |
---|---|---|---|---|---|---|
0FA — aucun facteur réel | ❌ (non défini) | ❌ | ❌ | ❌ | ❌ | ❌ |
1FA — un seul facteur (souvent mot de passe) | ⚠️ (AAL1) | ⚠️ (LoA1) | ❌ (insuffisant) | ❌ (contrôle continu requis) | ❌ pour comptes sensibles | ❌ (hors périmètre FIDO fort) |
2FA — deux facteurs distincts | ✅ (AAL2) | ✅ (LoA3 minimal) | ✅ (selon contexte/qualifié) | ⚠️ (à compléter par vérif. continue) | ✅ (exigé pour privilèges) | ✅ (clé/biométrie locale) |
MFA — ≥2 facteurs + contexte | ✅ (AAL3 = fort) | ✅ (LoA3/LoA4) | ✅ (services publics, eID qualifié) | ✅ (pilier ZTA) | ✅ (bonne pratique) | ✅ (si non synchronisé cloud) |
Lecture rapide :
- 0FA/1FA : peu ou pas reconnus pour des usages sensibles — non conformes aux doctrines modernes.
- 2FA : accepté par la plupart des cadres, mais qualité d’environnement non évaluée (DOM/cloud).
- MFA : attendu par tous les référentiels — robustesse conditionnée à l’indépendance des facteurs et à l’absence de synchronisation.
Réflexion stratégique — enjeux Zero-DOM de l’Authentification Multifacteur
Cette chronique démontre une évidence inconfortable : la sécurité d’une authentification ne dépend pas seulement du nombre de facteurs, mais de l’environnement et de la vérifiabilité.
Un 2FA mal injecté vaut moins qu’un 1FA robuste hors DOM. Un MFA « cloud-synchronisé » peut s’effondrer comme un château de cartes face à un proxy ou un push-bombing. Les référentiels normatifs eux-mêmes (NIST, eIDAS, ISO) reconnaissent ces pratiques, mais n’intègrent pas encore les critères de souveraineté numérique — validation hors navigateur, hors cloud, avec preuve cryptographique locale.
Implications pour les États
- Les doctrines Zero Trust et NIS2 imposent d’élever le plancher : sortir les secrets des environnements vulnérables.
- Un identifiant ou un OTP ne devient souverain que s’il est lié cryptographiquement à un hardware vérifiable.
- eIDAS 2.0 et les futures cartes d’identité numériques doivent éviter la dépendance cloud pour conserver une légitimité juridique.
Implications pour les entreprises
- Éviter le faux confort d’un MFA « marketing » qui masque en fait un single point of failure.
- Mettre en place des politiques Zero-DOM : secrets injectés uniquement via HSM, smartcards, enclaves sécurisées.
- Repenser l’expérience utilisateur pour concilier sécurité forte et usage fluide : NFC, biométrie locale, attestations.
Implications pour les citoyens
- Ne pas croire qu’un SMS ou un push suffisent — comprendre les limites des OTP.
- Privilégier les clés matérielles et passkeys non synchronisées.
- Demander des preuves de souveraineté : où sont stockés mes secrets ? Qui contrôle leur vérification ?
L’email comme identifiant — sujet incontournable et pragmatique
Oui, la réalité produit-utilisateur impose souvent l’adresse e-mail comme identifiant et canal de preuve de propriété : facilité d’expérience, ubiquité, réglementation, et écosystème (notifications, récupération). Cela rend la « suppression pure et simple » de l’email rarement praticable.
Pour autant, il est indispensable d’expliquer : l’email augmente la surface d’attaque. La stratégie raisonnable n’est pas d’interdire l’e-mail partout du jour au lendemain, mais de le traiter différemment — comme canal de contact, jamais comme premier degré d’autorité pour les opérations sensibles — et d’introduire des mesures progressives pour réduire sa criticité.
Position recommandée — Parler ouvertement du risque email dans la chronique, puis proposer une feuille de route pragmatique :
- atténuations obligatoires quand on ne peut pas supprimer l’email ;
- alternatives progressives pour migration (handles, UUID, WebAuthn, clés matérielles) ;
- experimentation et phasage (pilot, cohorts, mesure d’impact UX et sécurité).
Mesures pragmatiques quand l’email reste obligatoire
- Séparer identité (login) & contact — stocker un
user_id
opaque (UUID) pour authentifier, et utiliser l’e-mail seulement comme canal de contact/récupération sous conditions strictes. - Durcir les flows de réinitialisation — ne pas permettre un reset complet uniquement via e-mail pour comptes sensibles : exiger seconde preuve hors-DOM (HSM-signed challenge, OTP matériel, WebAuthn, appel vocal avec challenge, vérif. biométrique locale).
- Réponses opaques à l’énumération — ne pas indiquer si un e-mail existe ; réponses homogènes et timers, rate-limit et CAPTCHA adaptatif.
- Verrouiller les changements d’adresse — tout changement d’e-mail requiert attestation forte (device binding + preuve locale) et délai/cool-down, notifications sur tous les devices et sur l’ancien e-mail.
- Attacher device binding — quand l’e-mail est utilisé, lier les actions sensibles à une preuve de possession du device (certificat, attestation authenticator, HSM) pour empêcher takeover via boîte mail compromise.
- Renforcer la vérification initiale — pas seulement « clic sur lien » : attacher la vérification à un token court, usage unique, non stocké dans le DOM et signé par le serveur.
- Surveiller & alerter — détection automatique des tentatives de takeover, anomalies login, et triggers immédiats pour verrouillage MFA et investigations.
Alternatives progressives (phasing & migration)
- Introduire un handle / pseudonyme dès l’inscription et permettre le login via handle + WebAuthn/clé matérielle ; laisser l’e-mail comme canal de secours mais non-authentifiant.
- Offrir l’option WebAuthn / clé physique comme méthode primaire — promotion lors de la première connexion et campagne d’adoption.
- Migrations graduelles — cohortes : beta interne → power users → grand public ; mesurer friction et abandon à chaque étape.
- Federated identity / ID provider — proposer des IdP sécurisés (entreprise / eID qualifié) comme alternative pour comptes sensibles, tout en conservant l’e-mail pour notifications.
Checklist courte pour décider/oublier l’e-mail comme login (pour PM/archi)
- Peut-on remplacer l’email par un identifiant opaque sans casser l’UX critique (notifications légales, facturation) ? Si oui → plan de migration.
- Si non : quelle est la sensibilité des comptes ? (low / medium / high). Appliquer durcissements proportionnels.
- Implémenter : opaque IDs, existence-opaque responses, rate-limit, hardened reset, device binding, attestation pour changements d’email.
- Mesurer : métriques d’adoption WebAuthn, taux d’abandon lors du signup, incidents takeover, volume de resets.
- Communiquer : UX copy explicite, aides à l’option handle/clé matérielle, support pour onboarding.
« Dans l’idéal, l’adresse e-mail ne devrait pas être le login primaire ; dans la pratique, elle l’est souvent. Le texte le plus utile pour un architecte est donc : si vous ne pouvez pas l’éliminer immédiatement, traitez-la comme un canal de contact étroitement contrôlé — jamais comme la preuve unique de propriété — et mettez en place des protections hors-DOM pour toute opération sensible. »
[/col]Périmètre volontairement non traité — focale Authentification Multifacteur
Cette chronique se concentre sur l’anatomie des facteurs d’authentification (FA), leur robustesse selon l’environnement (DOM, cloud, OS, Zero-DOM), et leur rôle dans une doctrine de souveraineté numérique. Certains sujets connexes ont été volontairement exclus pour ne pas diluer le propos.
- Cryptographie avancée — Nous ne détaillons pas les protocoles sous-jacents (TLS, Diffie-Hellman, signatures elliptiques), sauf quand ils conditionnent directement la validité d’un FA.
- Gestion des identités (IAM, SSO, federation) — Abordée uniquement sous l’angle de la compromission des jetons (OAuth, SAML).
- Usages biométriques étendus — La biométrie locale est traitée comme facteur, mais les débats éthiques et légaux (CNIL, RGPD) ne sont pas couverts en détail.
- Aspects légaux et géopolitiques — Réglementations internationales, lois nationales ou doctrines militaires ne sont qu’évoquées (NIS2, eIDAS) mais non analysées en profondeur.
- Expérience utilisateur (UX) — Mentionnée comme vecteur d’attaque (MFA fatigue, overlay phishing), mais l’ergonomie globale n’est pas traitée.
- Hardware spécialisé — TPM, enclaves sécurisées, Secure Elements sont mentionnés comme contre-mesures, sans entrer dans l’architecture matérielle détaillée.
- Intelligence artificielle et machine learning — Les usages de l’IA/ML dans la détection d’anomalies d’authentification ou dans l’adaptive MFA ne sont pas traités ici. Ils feront l’objet de développements séparés, car ils relèvent d’une logique prédictive plus que d’une typologie de facteurs.
- Implémentation pratique grand public — Cette chronique n’aborde pas les guides d’activation de l’Authentification Multifacteur sur des services commerciaux (Google, Microsoft, réseaux sociaux). Elle reste centrée sur la doctrine souveraine, au-delà des tutoriels grand public.
Glossaire typologique de l’Authentification Multifacteur
Ce glossaire fixe les termes essentiels employés dans la chronique, afin d’éviter toute ambiguïté entre identifiant, facteur et environnement technique.
Terme | Définition |
---|---|
Facteur d’authentification (FA) | Élément vérifiable utilisé pour prouver l’identité. Trois catégories classiques : connaissance (mot de passe), possession (objet, token), inhérence (biométrie). |
0FA | Authentification sans facteur réel. Exemple : identifiant + mot de passe saisis dans un navigateur, sans vérification de possession ni d’inhérence. |
1FA | Authentification à un seul facteur, souvent un mot de passe. Vulnérable au phishing, au bruteforce et aux attaques DOM. |
2FA | Authentification à deux facteurs distincts. Exemple : mot de passe (connaissance) + token matériel (possession). Considéré comme le minimum acceptable. |
MFA | Authentification multifactorielle. Combine au moins deux facteurs distincts, parfois enrichis de contexte (réseau, localisation, temps). Forte seulement si les facteurs sont indépendants et hors-DOM. |
Identifiant privé avancé | Identifiant attribué par un tiers de confiance, non devinable, non partagé, et vérifié comme preuve exclusive. Peut être requalifié en facteur de possession. |
DOM | Document Object Model. Interface du navigateur qui structure les pages web. Surface critique où les secrets ne doivent jamais transiter. |
Zero-DOM | Doctrine consistant à exclure tout secret du DOM et du cloud, en privilégiant une vérification hors-OS via HSM, NFC ou sandbox matérielle. |
OTP | One-Time Password — mot de passe à usage unique. Inclut SMS OTP, email OTP, TOTP, HOTP, OTP matériel, push OTP. Leur robustesse varie fortement selon l’environnement d’injection. |
MFA fatigue / push-bombing | Attaque consistant à spammer des notifications push MFA jusqu’à ce que l’utilisateur accepte par erreur ou par lassitude. |
Overlay phishing | Technique de phishing par superposition d’une fausse interface (ex. WebAuthn, passkeys) sur une fenêtre légitime, pour voler un facteur. |
FAQ Typologique — Bonnes pratiques d’Authentification Multifacteur
Le 2FA désigne l’usage de deux facteurs distincts (par exemple mot de passe + OTP SMS). Le MFA va plus loin : il implique au moins deux facteurs, mais souvent trois ou plus, combinant connaissance (mot de passe), possession (clé matérielle, smartphone) et inhérence (biométrie). Dans la pratique, beaucoup de services présentent un 2FA limité comme un MFA, ce qui crée une confusion. La véritable différence réside dans la diversité et l’indépendance des facteurs. Un MFA robuste, de préférence actif et Zero-DOM, assure une sécurité bien supérieure à un simple 2FA.
Parce qu’un identifiant et un mot de passe dans le navigateur ne constituent pas deux facteurs, ni même un seul. Aucun élément vérifiable n’est engagé : c’est donc une authentification sans facteur, appelée 0FA. Cette situation est encore courante dans de nombreux services, où l’utilisateur croit être protégé par une simple combinaison identifiant/mot de passe. En réalité, il s’agit d’un schéma vulnérable aux attaques triviales, notamment le phishing, le credential stuffing et les keyloggers. La doctrine 0FA met en évidence cette illusion de sécurité.
Non. Même robuste, long et unique, un mot de passe reste stocké et injecté dans des environnements exposés (DOM, OS, cloud). Il constitue uniquement un facteur de connaissance, vulnérable au phishing, à l’interception réseau ou à la compromission locale. Les attaques modernes ciblent moins la force du mot de passe que l’environnement dans lequel il est utilisé. C’est pourquoi la sécurité numérique actuelle exige au minimum une authentification multifacteur, idéalement déployée hors DOM pour échapper aux compromissions.
Oui, mais faible. Le SMS repose sur la possession de la carte SIM, mais celle-ci peut être détournée (SIM swap), interceptée ou manipulée par l’opérateur. Le SMS OTP constitue donc bien un 2FA fonctionnel, mais non souverain, exposé au phishing et aux attaques à grande échelle. Pour les accès critiques ou réglementés (RGPD, NIS2), il est recommandé de migrer vers des facteurs plus robustes : TOTP hors DOM, clés NFC, ou MFA souverain Zero-DOM.
Elles ne le sont que si elles sont locales. Une passkey stockée dans un HSM, une enclave matérielle ou un appareil dédié est robuste. Mais une passkey synchronisée dans le cloud perd son exclusivité et peut être compromise en cas d’attaque contre l’infrastructure distante. Elle devient alors équivalente à un facteur passif. La souveraineté impose donc des passkeys locales et non synchronisées, intégrées dans un MFA actif.
Un facteur souverain se caractérise par :
- ✓ Une vérification hors DOM et hors cloud
- ✓ Une absence de synchronisation automatique
- ✓ Une validation locale (NFC, HSM, sandbox matérielle)
- ✓ Une exclusivité prouvée et non réplicable
Ces critères distinguent un simple facteur technique d’un facteur souverain, adapté à la cybersécurité avancée.
Oui. Par exemple, deux facteurs de même catégorie (mot de passe + question secrète) ou injectés dans le même environnement (mot de passe + TOTP dans le DOM) ne créent pas une véritable barrière. C’est ce que la doctrine appelle les « faux MFA ». Ils multiplient les étapes mais ne renforcent pas la sécurité. Seul un MFA souverain, avec indépendance des facteurs et architecture active, élève réellement le niveau de protection.
Oui, lorsque c’est possible. Un identifiant unique, non devinable, complique la tâche d’un attaquant et réduit l’exposition. Cependant, de nombreux services imposent l’email comme login et comme vecteur de contrôle de propriété. Dans ces cas, seule une authentification multifacteur souveraine, avec un facteur actif hors DOM, compense cette fragilité structurelle.
Ils font partie des meilleures options, à condition d’être provisionnés hors DOM (via HSM, PKI) et utilisés localement. Ils offrent une possession exclusive et une validation indépendante du cloud. Intégrés dans une MFA active, ils constituent un pilier souverain de l’authentification forte.
Parce que le DOM est une surface d’exposition universelle. Toute donnée qui y transite (mot de passe, OTP, jeton) peut être exfiltrée par extension, iframe invisible ou injection JavaScript. Tant qu’un facteur réside dans le DOM, il reste vulnérable. La doctrine Zero-DOM s’impose comme contre-mesure souveraine en retirant les facteurs de cette surface compromise.
Oui, dans certains cas. Une 1FA basée sur un identifiant cryptographique injecté hors DOM (par exemple via une clé matérielle) peut offrir plus de robustesse qu’une MFA où les facteurs sont synchronisés ou stockés dans le cloud. Ce n’est pas le nombre de facteurs qui compte, mais leur indépendance, leur exclusivité et leur environnement de validation.
Indirectement, oui. Le RGPD, via son article 32, impose la mise en œuvre de mesures de sécurité adaptées aux risques, ce qui inclut l’authentification forte. NIS2, de son côté, cible explicitement la robustesse de l’authentification et la résilience des infrastructures critiques. Pour les secteurs régulés (banque, santé, énergie), une MFA souveraine et active n’est pas seulement une bonne pratique, mais une exigence implicite de conformité.
Lectures complémentaires — mettre en pratique l’Authentification Multifacteur
- DOM Extension Clickjacking — DEF CON 33
Exfiltration silencieuse des identifiants, mots de passe, TOTP et passkeys injectés dans le DOM via iframe invisible et appelfocus()
Article technique publié chez Freemindtronic ↗ - WebAuthn API Hijacking — Guide CISO
Contournement des passkeys synchronisés par overlay phishing et injection WebAuthn dans le navigateur
Guide souverain publié chez Freemindtronic ↗ - Rubrique Digital Security — corpus thématique
Ensemble d’articles techniques et stratégiques sur les identifiants, la souveraineté, les architectures Zero-DOM et les vulnérabilités modernes
Accès direct à la rubrique Digital Security ↗