Deux invites de mot de passe ne font pas une MFA : ce qu'une connexion VPN vérifie

La page de connexion demande un mot de passe, puis un second secret, et le déploiement est aussitôt décrit comme multifacteur. Parfois, il l’est. Souvent, c’est un seul facteur collecté deux fois, car les deux valeurs sont des connaissances que la même personne a tapées de la même mémoire ou de la même note. Un chiffrement de tunnel robuste n’y change rien, et le mot « sécurisé » dans le nom du produit non plus.

Séparer l’affirmation du mécanisme ne demande qu’une question : que prouve chaque étape, et à qui ?

Un facteur est une preuve, pas un champ

L’authentification multifacteur signifie que plus d’une catégorie distincte de preuve est vérifiée pour le même compte : quelque chose que l’utilisateur sait, quelque chose qu’il possède, quelque chose qu’il est. Deux champs qui collectent tous deux une chaîne mémorisée sont une seule catégorie de preuve demandée deux fois. Cela peut être un contrôle utile, car deux secrets indépendants sont plus difficiles à deviner qu’un seul, mais ce n’est pas ce que le terme décrit et cela ne doit pas être compté comme tel dans une analyse de risque.

Le côté vérification compte autant que le côté collecte. Un code généré sur un appareil ne prouve le contrôle de cet appareil que si le serveur le vérifie contre un secret lié à ce compte et rejette les rejeux. Un code partagé qui fonctionne pour tout le monde, un code sans limite de débit ou une invite approuvée sur un appareil qui n’affiche jamais ce qui est approuvé sont tous plus faibles que l’étiquette ne le suggère.

Donc, quand quelqu’un demande si le VPN dispose d’une MFA, demandez ce que la seconde étape prouve et comment le serveur la lie. Si la réponse est « un second mot de passe issu du même annuaire », vous avez un facteur et une conversation sur la politique, pas un second facteur.

Le cas du certificat se lit, il ne se suppose pas

Un certificat client plus un mot de passe ressemble à deux facteurs, et cela peut l’être : le certificat est conservé dans un magasin ou sur un jeton, et le mot de passe est mémorisé. Cela peut aussi n’en être qu’un, si le fichier de certificat se trouve sans protection dans le même répertoire de profil que le mot de passe enregistré, ou si le certificat a été délivré à un appareil que plusieurs personnes partagent sans responsabilité individuelle.

La question à trancher est qui ou quoi le certificat identifie. Un certificat d’appareil prouve qu’une machine administrée est présente. Un certificat d’utilisateur prouve une identité. Si le déploiement émet un certificat par ordinateur portable puis traite sa présence comme preuve de la personne, le second facteur est discrètement devenu une propriété du matériel que quiconque tient l’ordinateur hérite.

Rien de tout cela ne fait des certificats une mauvaise idée. Cela rend la distinction entre assurance de l’appareil et assurance de l’utilisateur digne d’être écrite, parce que les deux répondent à des questions différentes et un tableur de conformité qui les compte comme une seule surévaluera ce qui est protégé.

La confiance envers la passerelle et la confiance envers l’utilisateur sont des problèmes distincts

Un second facteur ne rend pas sûr le fait de saisir des identifiants dans un point de terminaison que vous n’avez pas vérifié. Le client doit reconnaître la passerelle prévue, et c’est à cela que servent le certificat du serveur et la configuration de confiance du client. L’hameçonnage fonctionne en déplaçant la connexion vers un serveur que l’attaquant contrôle, et un code à usage unique correct saisi là-bas est simplement relayé au vrai service en temps réel.

C’est pourquoi le choix de la méthode change plus le résultat que la formulation de l’invite. Les codes tapés par une personne peuvent être relayés par quiconque peut présenter une page convaincante, tandis que les méthodes cryptographiques qui lient l’authentification à l’origine et à la session précises résistent à ce relais par conception. Laquelle des deux vous avez est une propriété de la méthode, pas du nombre d’étapes dans la boîte de dialogue.

Suivez le parcours d’inscription et de client pris en charge par le fournisseur plutôt que de boulonner une invite supplémentaire sur un champ de mot de passe. Une seconde étape maison finit généralement quelque part entre les deux, en ajoutant des frictions sans la liaison qui donne son sens au facteur.

La récupération est la seconde porte d’entrée

Toute connexion forte a un chemin de retour lorsque l’authentificateur est perdu, et ce chemin est là où la conception est généralement la plus faible. Si un agent de support peut réinitialiser le second facteur après un appel à un numéro enregistré, la route la moins chère pour l’attaquant est le service d’assistance, pas la page de connexion.

Demandez comment fonctionne le remplacement, qui l’approuve et quelles preuves sont exigées. Vérifiez ensuite que le matériel de récupération, comme les codes de secours, est stocké séparément de l’identifiant principal, afin qu’une seule compromission ne livre pas les deux. Les recommandations sur l’identité numérique du NIST traitent la liaison du vérificateur et le cycle de vie de l’authentificateur comme faisant partie de l’exigence, et non comme une réflexion opérationnelle.

Ce qu’il faut écrire dans l’évaluation

Décrivez les facteurs par catégorie, nommez ce que chacun prouve et indiquez comment il est lié au compte. Notez si la méthode résiste au relais, et décrivez le chemin de récupération avec le même soin que la connexion.

Dites ensuite clairement si le déploiement est multifacteur selon cette définition. « Deux mots de passe et un certificat de machine » est une phrase honnête, et elle apprend bien plus à un lecteur qu’une case à cocher qui dit oui.