Comprendre les parcours d'authentification

L'écran de connexion doit aider l'utilisateur légitime à entrer sans donner d'informations utiles à un attaquant. Il constitue un point d'entrée critique du point de vue de la sécurité.

Un message trop précis aide l'utilisateur, mais renseigne aussi l'attaquant. Un message trop vague protège le système, mais perd l'utilisateur. La conception du parcours d'authentification doit permettre de concilier ces deux exigences et pour y parvenir, il est nécessaire de considérer le parcours dans son ensemble : la saisie, l'erreur, le blocage, l'aide, le second facteur, la session.

Note : cet article s'appuie sur les exigences d'authentification de NIST1 et sur plusieurs guides pratiques d'OWASP, sur le login2, la session3, la réinitialisation4 et le second facteur5.

Le flux « identifiant d'abord »

Parfois, demander l'identifiant en premier permet d'orienter l'utilisateur vers la bonne méthode plutôt que de l'obliger à choisir :

• Une décision à la fois : "qui es-tu ?" puis "prouve-le". Le second écran est adapté à la personne, pas générique.
• Selon l'identifiant saisi, l'écran propose le SSO de l'organisation, une passkey déjà enregistrée, ou le mot de passe, sans afficher cinq options en même temps.
• Le champ d'identifiant peut déclencher l'interface conditionnelle WebAuthn : le navigateur propose la passkey du compte directement dans l'autofill, sans bouton dédié.

Les champs

Un champ e-mail correctement déclaré ouvre le bon clavier et désactive la correction automatique, qui sinon « corrige » l'adresse saisie. Un champ de code à usage unique peut, lui, proposer directement le code reçu par SMS, sans aller-retour vers l'application de messagerie.

<!-- E-mail : bon clavier, pas de correction ni de majuscule auto -->
<input
  type="email"
  inputmode="email"
  autocapitalize="off"
  autocorrect="off"
  autocomplete="username">

<!-- Code OTP : suggestion automatique du code reçu par SMS -->
<input
  type="text"
  inputmode="numeric"
  autocomplete="one-time-code">

Les états

Qulques bonnes pratiques à prendre en compte sur les micro-états

• Désactiver le bouton dès le clic et montrer une progression, pour éviter la double soumission et rassurer.
• Valider au bon moment : à la sortie du champ, jamais à chaque frappe, et ne pas afficher d'erreur avant que le champ ait été quitté une première fois.
• Préserver la saisie : après un mot de passe refusé, ne jamais vider le champ e-mail. Refaire saisir l'adresse à chaque tentative est une punition gratuite.
• Signaler Caps Lock : un avertissement discret sur le champ mot de passe évite des échecs inexpliqués.

Le mot de passe

Sur le mot de passe lui-même, NIST privilégie la longueur plutôt que la complexité1 :

• SHALL Un mot de passe utilisé seul fait au moins quinze caractères.
• SHOULD Le système en accepte au moins soixante-quatre.
• SHALL NOT Les règles de composition imposées, une majuscule, un chiffre, un caractère spécial, sont écartées. Elles poussent vers des schémas prévisibles sans gagner en sécurité.

Un article detaillé sur les mots de passe est accessible ici

Les messages d'erreur

Quand une connexion échoue, la tentation est d'aider l'utilisateur en étant précis.
"Mot de passe incorrect" lui dit que son identifiant est bon. "Cet identifiant n'existe pas" lui dit l'inverse. Dans les deux cas, l'interface vient de confirmer une information à quiconque pose la question.

Un attaquant teste une liste d'adresses et trie celles qui "existent" de celles qui n'existent pas. C'est l'énumération de comptes. OWASP recommande un message générique, identique quel que soit le motif réel de l'échec2 (par ex : identifiant inconnu, mot de passe faux, compte désactivé ou verrouillé etc.) plutôt que d'exposer le motif réel.

Faut-il cacher si un compte existe ?

Cette neutralité a un inconvénient, qu'OWASP formule comme un problème d'expérience utilisateur2 : un message générique peut désorienter une personne de bonne foi, qui ne comprend pas ce qui cloche et finit par abandonner. Le compromis dépend donc de la criticité de l'application et de ses données.

C'est pourquoi certains services choisissent l'inverse assumé. Les connexions en 2 étapes : d'abord l'adresse puis le mot de passe, révèlent souvent qu'un compte existe avant même de demander le secret. Ce choix améliore le parcours, mais il rend l'énumération possible. On peut l'accepter uniquement si d'autres protections empêchent d'en tirer profit.Empêcher les tentatives massives prive l'énumération de son intérêt, puisqu'un attaquant ne peut plus tester des milliers d'adresses2.

Par exemple :

• Rate limiting : après X tentatives, on bloque l'IP
• CAPTCHA : énumérer des milliers d'adresses devient humainement impossible
• MFA obligatoire : même si l'attaquant sait qu'un compte existe, il ne peut pas s'y connecter sans le second facteur
• Monitoring : détecter et alerter sur les patterns d'énumération

Il n'y a pas de réponse unique : le curseur entre confort et discrétion se place selon ce que l'application protège.

Limiter les tentatives sans punir l'utilisateur

Bloquer un compte après quelques échecs paraît prudent, mais le verrouillage peut se retourner contre l'utilisateur. Si n'importe qui peut verrouiller un compte en saisissant trois mauvais mots de passe, le blocage devient un moyen de déni de service contre l'utilisateur légitime.

NIST recommande la limitation de débit plutôt que le verrouillage dur1. Le système limite les tentatives échouées consécutives à cent par compte au maximum, après quoi l'authentificateur est désactivé. SHALL Ce nombre est un plafond, pas une cible : il peut être abaissé. MAY Un utilisateur honnête dépasse rarement quelques essais, alors qu'une attaque automatisée en tente des milliers. Plafonner à cent arrête la seconde sans gêner le premier.

NIST décrit trois moyens de réduire le risque de verrouiller un utilisateur légitime1. D'abord, un test anti-robot avant la tentative (reCAPTCHA v3 ou Turnstile). Ensuite, une attente qui s'allonge à chaque échec, par exemple de trente secondes jusqu'à une heure à mesure qu'on approche du plafond. Enfin, l'analyse de signaux d'alerte : une tentative venue d'une adresse IP ou d'un pays inhabituels, ou une cadence de saisie trop rapide pour un humain. Quand un de ces signaux apparaît, le système durcit la vérification, par un test anti-robot ou une étape supplémentaire, ou refuse la tentative. Après une connexion réussie, le compteur d'échecs repart de zéro. SHOULD

Côté interface, indiquer un ralentissement temporaire et la marche à suivre vaut mieux qu'un blocage sec sans explication. L'utilisateur doit comprendre qu'il pourra réessayer, et comment, sans que le texte ne révèle l'état exact du compte.

Aider en cas d'échec

Après un échec, l'interface doit guider l'utilisateur sans rouvrir la porte à la fuite d'information.4.

• Un lien "Mot de passe oublié ?" : qui reste visible et accessible dès le premier échec, pas seulement après 5 tentatives
• Un compteur discret : "2 tentatives restantes avant un délai d'attente" prévient sans bloquer brutalement
• Un message de ralentissement : "Trop de tentatives. Réessayez dans 30 secondes." avec un timer visible si possible

Plusieurs autres aides réduisent les échecs en amont, et NIST les classe selon leur force1 :

• SHALL Autoriser les gestionnaires de mots de passe et l'autofill est obligatoire.
• SHOULD Permettre le collage dans le champ est recommandé, quand l'autofill n'est pas disponible.
• SHOULD Proposer un bouton pour afficher le mot de passe saisi est recommandé aussi.

Ces bonnes pratiques réduisent la friction à la saisie et, combinées à un gestionnaire de mots de passe, favorisent des identifiants plus robustes.

<!-- Champ aidant le gestionnaire et l'autofill -->
<label for="password">Mot de passe</label>
<input
  id="password"
  type="password"
  autocomplete="current-password"
  aria-describedby="pw-help">
<button type="button" aria-pressed="false">Afficher</button>
<p id="pw-help">Le collage et les gestionnaires sont acceptés.</p>

Après la connexion : la session

Une fois l'utilisateur reconnu, c'est la session qui le maintient connecté, et c'est elle qui devient la cible. La première mesure est de régénérer l'identifiant de session juste après la connexion3.

La durée de vie de la session repose sur deux expirations combinées : une expiration d'inactivité, qui ferme la session après un temps sans activité, et une expiration absolue, qui la ferme au bout d'une durée fixe quoi qu'il arrive3.

L'accessibilité n'est pas une option

Depuis WCAG 2.2, ce n'est plus une bonne intention mais un critère normé, au même titre que les exigences NIST citées plus haut.

Le critère 3.3.8 Authentification accessible (minimum), niveau AA, interdit d'imposer un test de fonction cognitive (mémoriser, retranscrire, résoudre un puzzle) à une étape de la connexion, sauf à fournir une alternative8. Conséquence directe : autoriser les gestionnaires de mots de passe, l'autofill et le collage n'est plus un simple confort, c'est ce qui rend le parcours conforme. Le point vu plus haut sur l'autofill devient donc une obligation d'accessibilité, pas une commodité.

Trois points complètent le tableau, en lien avec les sections précédentes :

• Annoncer les erreurs. Un message d'erreur visuel reste invisible pour un lecteur d'écran s'il n'est pas signalé. Le conteneur doit porter un rôle d'alerte, et le focus se déplacer sur le message.
• Ne pas reposer sur la couleur seule. Vos blocs « À faire / À éviter » et vos états d'erreur doivent rester compréhensibles sans la couleur : une icône, un mot, une forme.
• Délais ajustables. Le critère 2.2.1 (niveau A) impose de prévenir et de pouvoir prolonger un délai8 : c'est exactement le rôle de l'alerte « votre session expire dans 2 minutes » décrite plus loin.

<!-- Zone d'erreur annoncée aux technologies d'assistance -->
<div
  id="login-error"
  role="alert"
  aria-live="assertive"></div>

<!-- Le focus se place sur ce conteneur après l'échec -->

Mesurer l'UX de l'authentification

L'authentification est un parcours, et comme tout parcours, elle laisse des traces qu'on peut suivre :

• Taux de réussite au premier essai. La proportion de connexions abouties sans erreur ni reprise.
• Time-to-auth. Le temps écoulé entre l'arrivée sur l'écran et l'accès effectif. Un allongement signale un parcours complexe.
• Taux de réinitialisation de mot de passe. Un taux élevé traduit souvent des identifiants oubliés faute de gestionnaire, ou un parcours qui force à en créer trop.

Le parcours idéal en un schéma

Mises bout à bout, voici la logique : demander le minimum à l'utilisateur légitime, router à sa place, et réserver la friction aux signaux de risque.