Ressources · 24
Déployer une authentification résistante au phishing
Choisir des facteurs liés au service légitime et protéger leur enrôlement, perte et révocation.
· 9 min
Ce que ce guide permet
- Cartographier les accès
- Choisir un protocole résistant
- Sécuriser l’enrôlement
- Exercer la récupération
Contrôle express
- Quels comptes donnent accès aux données ou fonctions critiques ?
- Le facteur est-il lié cryptographiquement au vrai service ?
- Qui autorise l’ajout d’un nouvel authentificateur ?
- Comment révoquer un appareil perdu ?
- Les exceptions ont-elles un responsable et une date de fin ?
Méthode pas à pas
- 01
Inventorier les chemins d’accès
Recenser applications, fédération, administrateurs, comptes de secours et méthodes actuelles. Repérer les connexions qui acceptent encore un code saisi manuellement.
Livrable : matrice comptes, applications et facteurs.
- 02
Choisir la résistance requise
Évaluer des protocoles cryptographiques liés au canal ou au nom du vérificateur, comme WebAuthn/FIDO2 lorsque l’application le permet. Un OTP recopié dans une page peut être relayé et n’est pas considéré résistant au phishing par le NIST.
Livrable : choix de méthode et limites connues.
- 03
Piloter sur les comptes sensibles
Tester navigateurs, appareils, délégation, usage hors ligne éventuel et accessibilité avec un groupe représentatif. Prévoir plusieurs moyens autorisés sans multiplier les accès dormants.
Livrable : scénario pilote et critères de succès.
- 04
Protéger l’enrôlement
Vérifier l’identité et la session avant d’ajouter une clé, notifier l’utilisateur et enregistrer l’événement. Tester le refus d’un enrôlement demandé depuis un contexte suspect.
Livrable : procédure et journal d’ajout.
- 05
Prévoir perte et révocation
Documenter le signalement, la désactivation, la récupération et le contrôle d’identité pour un moyen perdu. Tester ce parcours sans contourner la protection par un canal faible.
Livrable : exercice de récupération et révocation.
- 06
Étendre et surveiller
Déployer par groupes, mesurer la couverture, suivre les échecs et les exceptions, puis supprimer les méthodes anciennes quand le retour d’expérience permet de le faire.
Livrable : tableau de migration et registre des exceptions.
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Couverture | Comptes sensibles utilisant une méthode résistante | Étendre la migration |
| Enrôlement | Ajouts avec contrôle et notification | Corriger les chemins faibles |
| Récupération | Pertes simulées traitées sans contournement | Rejouer le scénario |
| Exceptions | Accès restants avec propriétaire et date | Résorber les anciens facteurs |
Erreurs fréquentes
- Qualifier tout MFA de résistant au phishing
- Protéger la connexion mais laisser un enrôlement faible
- Oublier les administrateurs et comptes de secours
- Supprimer l’ancien facteur avant de tester la récupération
Questions fréquentes
Un code à usage unique suffit-il ?
Le NIST précise qu’un code saisi manuellement peut être relayé par un faux service ; il n’établit donc pas une résistance au phishing.
Faut-il une clé physique pour chaque personne ?
La méthode dépend du niveau d’assurance et du contexte ; certains authentificateurs WebAuthn synchronisables peuvent convenir à certains usages, avec des choix de récupération adaptés.
Que faire après la perte d’un appareil ?
Révoquer le moyen concerné, suivre la procédure de récupération vérifiée et notifier l’utilisateur selon la politique du service.
Identités : facteurs, sessions et récupération
Une méthode d’authentification se juge avec son enrôlement, sa récupération et les sessions qu’elle ouvre. Le nom « passkey », l’usage d’un téléphone ou la présence d’un capteur biométrique ne démontrent pas, seuls, le niveau d’assurance de tout le service.
Repères issus de NIST SP 800-63B-4, finalisé en juillet 2025, et de WebAuthn Level 3, devenu recommandation W3C le 25 août 2026. Les AAL décrivent une transaction d’authentification ; ils ne sont ni une note de produit ni une certification obtenue en cochant ce tableau. Leur application dépend du périmètre du service et de son analyse de risque.
Sources consultées le .
Comparer huit méthodes sans confondre les garanties
| Méthode et référence | Propriété et conditions | Secours et dépendances | Preuve à demander |
|---|---|---|---|
| Mot de passe saisi | Facteur de connaissance ; un faux site peut relayer ou capturer le secret. | Dépend du gestionnaire de mots de passe et du parcours de remplacement du secret. | Politique de longueur, blocage des secrets compromis et essai du parcours de remplacement. |
| Code TOTP recopié | Preuve de possession d’un secret partagé ; sa saisie manuelle ne lie pas le code à la session légitime. | Prévoir la perte du générateur et la protection des graines ou sauvegardes du fournisseur. | Enrôlement autorisé, protection du secret et révocation ; ne pas qualifier tout OTP de résistant au phishing. |
| Code SMS ou vocal | Canal hors bande PSTN, soumis à restrictions dans le cadre NIST ; le code saisi n’est pas résistant au phishing. | Le numéro, l’opérateur et les changements de carte ou de ligne font partie des dépendances. | Justification du canal, signaux de risque, alternatives et procédure de changement du numéro. |
| Approbation push simple | Une approbation sans liaison cryptographique au nom ou au canal du vérificateur ne démontre pas la résistance au phishing. | Le téléphone perdu et la réinscription de l’application doivent être traités. | Protocole réel, intention de l’utilisateur et contrôles d’enrôlement ; le mot « push » seul ne suffit pas. |
| WebAuthn synchronisable avec UV | Preuve cryptographique liée au service ; la vérification utilisateur (UV) doit être exigée et contrôlée quand requise. Les clés synchronisables sont exportables au sens NIST. | Le compte de synchronisation, ses appareils et sa récupération entrent dans le périmètre de confiance. | Exigences de la synchronisation et de l’UV. Une méthode synchronisable ne convient pas à AAL3, qui interdit l’export des clés. |
| WebAuthn lié à un appareil avec UV | Liaison au service et vérification utilisateur. « Lié à l’appareil » ne démontre pas à lui seul une protection matérielle non exportable. | La perte de l’appareil exige un autre moyen autorisé ou un parcours de récupération contrôlé. | Propriétés du stockage, UV, preuve de non-exportabilité si nécessaire et tests des clients réellement utilisés. |
| Clé WebAuthn sans UV | Liaison au service, mais possession seule dans ce cas. Un toucher ou un indicateur de présence (UP) ne prouve pas une vérification utilisateur (UV). | Préparer une seconde méthode autorisée et la révocation de la clé perdue. | Vérification des indicateurs UP/UV et combinaison de facteurs requise par le service ; ne pas inférer MFA du seul format matériel. |
| Biométrie considérée seule | Dans le cadre NIST, la biométrie s’utilise avec un authentificateur physique en MFA ; ce n’est pas un secret ni un mécanisme autonome suffisant. | Prévoir une alternative non biométrique et protéger les données biométriques selon leur sensibilité. | Lieu de comparaison, rôle d’activation et alternative accessible ; distinguer comparaison biométrique et preuve cryptographique. |
Aucune méthode ne correspond aux filtres.
Trois niveaux AAL : exigences et recommandations distinctes
| Niveau et facteurs | Résistance et export des clés | Durée globale de réauthentification | Inactivité |
|---|---|---|---|
| AAL1 Un facteur peut suffire dans ce niveau. | Résistance au phishing non imposée par ce niveau ; export de clé permis. | 30 jours au plus : recommandation SHOULD. | Pas de plafond chiffré dans ce repère ; définir la politique du service. |
| AAL2 Deux facteurs distincts. | Une option résistante au phishing doit être proposée ; export de clé permis sous les conditions applicables. | 24 heures au plus : recommandation SHOULD ; une limite globale définie reste obligatoire. | 1 heure au plus : recommandation SHOULD. |
| AAL3 Authentificateur cryptographique et facteur supplémentaire ou d’activation. | Résistance au phishing et clé privée non exportable requises. | 12 heures au plus : exigence SHALL. | 15 minutes au plus : recommandation SHOULD. |
Les valeurs ne sont pas des durées à recopier aveuglément dans un cookie. Le NIST distingue limite globale et inactivité, puis décrit les règles de réauthentification. Une application peut retenir des durées plus courtes selon ses risques. IAL concerne la preuve d’identité et FAL la fédération : un AAL ne remplace pas ces deux dimensions. NIST §2 →
Mots de passe : sept repères précis du NIST
- Facteur unique
- Minimum 15 caractères requis.
- Dans une MFA
- Minimum 8 caractères requis si le mot de passe n’est utilisé que dans un processus multifacteur.
- Longueur acceptée
- Accepter une longueur maximale d’au moins 64 caractères est recommandé.
- Composition
- Pas de mélange imposé de types de caractères.
- Renouvellement
- Pas de changement périodique arbitraire ; imposer un changement en cas de preuve de compromission.
- Secrets à refuser
- Comparer aux listes de mots de passe courants, attendus ou compromis.
- Aide à la saisie
- Permettre les gestionnaires et le remplissage automatique ; autoriser le collage est recommandé.
Récupération : quatre classes, avec leurs conditions
- Code conservé à l’avance
- Au moins 64 bits aléatoires dans le cadre NIST ; conservation hors ligne par l’abonné, stockage haché côté service et invalidation après usage.
- Code envoyé à la demande
- Les codes émis par SMS ou voix sont valides au plus 10 minutes ; ceux envoyés par email au plus 24 heures. Vérifier les adresses et appliquer les exigences du niveau visé.
- Contact de récupération
- Organiser les adresses de contacts et les contrôles associés ; la relation humaine ne remplace pas les conditions techniques du parcours.
- Nouvelle preuve d’identité
- Option pour les comptes dont l’identité avait été vérifiée. Si aucune preuve d’identité n’a été réalisée, ne pas prétendre « revérifier » une identité inconnue.
Remplacer un mot de passe oublié en utilisant un autre authentificateur encore valide relève de l’association d’un nouveau moyen, pas nécessairement d’une récupération de compte. Documenter les notifications, délais, révocations et responsabilités évite de transformer le support en contournement. NIST §4 →
Relier authentification, session et incident
| Étape | Contrôle concret proposé | Preuve observable |
|---|---|---|
| Enrôler | Vérifier qui autorise l’ajout du moyen et notifier le titulaire par un chemin connu. | Trace de l’ajout, moyen associé et justification de l’autorisation. |
| Authentifier | Vérifier le protocole, le domaine attendu et les facteurs exigés avant d’ouvrir l’accès. | Résultat d’essai sur les clients retenus, avec les indicateurs de présence et de vérification séparés. |
| Gérer la session | Définir expiration globale, inactivité, réauthentification des actions sensibles et invalidation à la déconnexion. | Essais de session expirée, déconnexion et accès après révocation. |
| Signaler la perte | Identifier l’authentificateur concerné, préserver les traces utiles et décider des invalidations selon la compromission suspectée. | Chronologie du signalement et résultat du contrôle d’accès après traitement. |
| Récupérer | Appliquer un parcours documenté, notifier et empêcher qu’une ancienne session ajoute un nouveau moyen sans contrôle approprié. | Scénario de récupération réussi et scénario de contournement refusé. |
| Sortir du service | Retirer les moyens et accès devenus inutiles ; traiter aussi les sessions, appareils et autorisations de synchronisation pertinents. | État des moyens révoqués, accès supprimés et dépendances résiduelles. |
WebAuthn : vérifier la réponse côté service
Le serveur doit notamment rapprocher le challenge, l’origine autorisée, l’empreinte du RP ID et la signature de la cérémonie attendue, puis contrôler les indicateurs requis. UP indique une présence ; UV indique une vérification utilisateur. BE et BS décrivent l’éligibilité et l’état de sauvegarde de l’identifiant, sans certifier à eux seuls le dispositif de synchronisation. Utilisez une bibliothèque maintenue et les procédures complètes des sections 7.1 et 7.2 du standard. WebAuthn Level 3 →
Inclure les personnes qui utilisent un autre parcours
Le critère WCAG 2.2 3.3.8, de niveau AA, encadre les tests cognitifs lors de l’authentification avec des exceptions et mécanismes d’aide précis. Vérifiez concrètement gestionnaire de mots de passe, collage, libellés, clavier, annulation et solution de secours. Une option non biométrique doit rester disponible dans le cadre NIST ; la rendre utilisable fait partie de la conception. WCAG 2.2 · 3.3.8 →
Poursuivre avec la gouvernance des identités →
Références primaires et périmètre
Dates de publication et consultation sont distinctes. Les propositions de tests et preuves sont éditoriales ; les textes normatifs liés font foi. Les documentations de fournisseur décrivent leur propre produit et n’attestent pas un niveau AAL de votre application.
- NIST SP 800-63B-4 · final publication · Publication :
- NIST · Authentication Assurance Levels · Publication :
§2.1–2.3 - NIST · Authenticators and password requirements · Publication :
§3.1.1; §3.2.3; §3.2.5 - NIST · Authenticator Event Management · Publication :
§4.1; §4.2; §4.6 - NIST · Session Management · Publication :
§5 - NIST · Syncable Authenticators · Publication :
Appendix B - W3C · WebAuthn Level 3 · Publication : · W3C Recommendation
§6.1; §7.1–7.2 - W3C · Accessible Authentication (Minimum) · Publication :
WCAG 2.2 · 3.3.8 · AA
Formulaires : critères, erreurs et contraste
Authentifier sans imposer un effort cognitif évitable
Le critère 3.3.8 encadre les tests cognitifs à chaque étape d’authentification avec des alternatives, mécanismes d’aide et exceptions précis. La sécurité et l’utilisabilité doivent être vérifiées ensemble.
- Essayer gestionnaire de mots de passe et collage lorsque pertinents.
- Examiner les mécanismes de secours dans le parcours réel.
- Ne pas déduire l’accessibilité d’un écran du seul choix d’une technologie d’authentification.
Ouvrir la grille WCAG et le calculateur de contraste →
W3C WAI · Understanding SC 3.3.8 · Accessible Authentication (Minimum) · Informative explanation · consulted 2026-10-23
Références officielles
Date de consultation des références : . La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.
- NIST SP 800-63B-4 — phishing resistance and authenticator lifecycle
- CISA — Cross-Sector Cybersecurity Performance Goals
- NIST SP 800-63B-4 · final publication
- NIST · Authentication Assurance Levels
- NIST · Authenticators and password requirements
- NIST · Authenticator Event Management
- NIST · Session Management
- NIST · Syncable Authenticators
- W3C · WebAuthn Level 3
- W3C · Accessible Authentication (Minimum)
- W3C · Web Content Accessibility Guidelines (WCAG) 2.2
- W3C WAI · Understanding SC 3.3.8 · Accessible Authentication (Minimum)
Pour aller plus loin
Analyses associées
