Demande MFA VPN refusée : que doit faire le client

Une demande MFA refusée ressemble à un problème réseau et n’en est pas un. Le serveur a demandé un second facteur, le facteur est revenu négatif ou n’est jamais arrivé, et la session a été refusée avant même qu’un tunnel existe. Ce qui se passe ensuite est une question de comportement du client : exposer l’échec et laisser l’utilisateur repartir sur une tentative propre, ou réessayer d’une manière qui génère davantage de demandes et finit par déclencher la protection du compte. La seconde voie est celle par laquelle un code mal saisi devient un compte verrouillé.

Vérifier quelle demande a échoué

Commencez par identifier quelle demande a échoué. Une notification push, un code TOTP, une assertion FIDO et un flux SAML échouent chacun différemment, et le client sait généralement lequel il a demandé. Un refus, un défi expiré et un échec de distribution qui n’a jamais atteint l’appareil se terminent tous par la même erreur générique, si bien que l’état du client lui-même est souvent le seul endroit où la différence survit.

Cet état mérite d’être consigné avec précision. Enregistrez l’identifiant du défi ou la référence de transaction, le type de facteur, l’horodatage et le résultat, mais jamais le code ni l’assertion. L’identifiant du défi est ce qui permet à un administrateur de retrouver l’événement côté fournisseur d’identité ; sans lui, la conversation avec le support commence par « à un moment dans la dernière heure » et s’arrête généralement là. Traitez-le comme une métadonnée de diagnostic, pas comme un secret.

Réessayer une fois, délibérément, avec un nouveau défi

Une reprise doit être une nouvelle tentative avec un nouveau défi, pas une relecture de l’ancien. Lorsque le client réutilise le défi précédent, le fournisseur d’identité soit le rejette comme périmé, soit, pire, accepte une approbation destinée à la tentative antérieure. Demandez un défi neuf, affichez-le et laissez l’utilisateur agir sur celui qui est à l’écran à cet instant.

Deux tentatives avec une courte pause entre elles constituent une valeur par défaut raisonnable ; une boucle sans limite n’en est pas une. Si la seconde tentative échoue de la même manière, arrêtez-vous et signalez-le plutôt que de continuer.

Ce que le client ne doit pas faire

Le client ne doit pas faire plusieurs choses qui semblent utiles et ne le sont pas. Il ne doit pas continuer à envoyer des notifications push jusqu’à ce que quelqu’un appuie sur « approuver », car cela habitue les utilisateurs à approuver des demandes qu’ils n’ont pas initiées et c’est exactement le comportement sur lequel reposent les kits d’hameçonnage. Il ne doit pas se rabattre sur un facteur plus faible parce que le fort a échoué, et il ne doit pas désactiver la vérification de l’identité du serveur pour contourner une plainte de certificat apparue au même moment. Chacun de ces trois raccourcis transforme un échec d’authentification en incident de sécurité.

Il ne doit pas non plus avaler l’échec en silence. Un client qui ferme la connexion et affiche un indicateur de chargement laisse l’utilisateur sans aucune idée de s’il faut réessayer, attendre ou appeler le support. Exposez l’échec avec le type de facteur et un code court, gardez le message exempt de secrets et rendez l’action de reprise explicite plutôt qu’automatique.

Si la demande n’a pas été initiée par la personne au clavier, la bonne action est de la laisser refusée et de la signaler par le canal de support vérifié. Approuver une demande pour faire cesser le bruit est le mode de défaillance, pas la correction.

Ce qu’il faut consigner pour le support

Pour le support, l’enregistrement utile est mince. L’heure approximative avec le fuseau horaire, le compte, le client et la version, le type de facteur et le statut non secret de chaque tentative : demandée, refusée, expirée, approuvée mais rejetée par la politique.

Gardez aussi les horloges du client et du serveur à l’esprit. TOTP est un contrôle de fenêtre temporelle, donc un appareil dont l’horloge a dérivé produit des codes d’apparence valide qui échouent à chaque fois, et un client qui signale un code invalide sans noter la dérive envoie les gens réinitialiser des identifiants qui n’ont jamais été faux. Un utilisateur dont la connexion échoue à répétition devrait vérifier la version prise en charge du client, l’état d’enrôlement et le parcours de récupération documenté avant de générer davantage de demandes.

Le parcours de récupération mérite le même soin que le parcours de connexion. Un parcours pour appareil perdu existe précisément pour qu’un refus ne devienne pas une autorisation de contourner l’authentification, et un client devrait renvoyer au processus documenté de l’organisation plutôt que d’en improviser un.

La règle sur laquelle construire est qu’un refus est un résultat, pas un obstacle. Signalez-le une fois, clairement, avec assez de contexte pour agir, et laissez la tentative suivante être nouvelle. Les recommandations de la CISA sur le MFA résistant au hameçonnage expliquent pourquoi le schéma « demander jusqu’à approbation » est dangereux dès le départ, et c’est la référence à citer lorsqu’une personne propose une boucle de reprise. Tout ce que le client ajoute après un refus devrait rendre la décision suivante plus facile pour un humain, non la lui retirer.