Votre mot de passe VPN n’est privé qu’autant que son vérificateur

Passez en revue quatre questions sur toute connexion VPN : ce qui protège le mot de passe en transit, quel composant le reçoit, ce que ce composant en fait, et ce qui est stocké ensuite. Chaque réponse est un contrôle différent, et une réponse solide à l’une ne dit rien des autres. L’erreur est de traiter le chiffrement du tunnel comme s’il couvrait les quatre. Il couvre la première, et seulement la première.

Demandez qui termine la session plutôt que si la session est chiffrée.

Chiffré pour qui, exactement ?

TLS protège le mot de passe entre le client et ce qui termine la connexion. Si ce point de terminaison est la passerelle VPN, le code d’authentification de la passerelle voit le mot de passe en clair, le valide et transmet ensuite celui-ci ou une valeur dérivée. C’est la conception prévue, pas une fuite. Un observateur réseau sur le chemin n’apprend rien d’utile, et le composant qui effectue la vérification apprend tout ce dont il a besoin.

La communauté OpenVPN le documente explicitement : auth-user-pass-verify remet les identifiants soumis à un script ou à un greffon de vérification. C’est une remise intentionnelle entre composants, et elle appartient au modèle de confiance comme partie nommée.

Le vérificateur voit le mot de passe

Dès qu’un composant reçoit un mot de passe pour le vérifier, ses contrôles d’accès, sa journalisation et la qualité de son code décident si le secret reste confiné. Un script qui écrit l’identifiant dans un journal, ou un greffon qui le met en cache, crée une exposition bien plus grande que ne l’a fait le protocole. L’accès dépend de l’architecture et des rôles, non du tunnel, et c’est pourquoi le propriétaire du service qui contrôle le vérificateur relève de l’évaluation.

Des méthodes différentes exposent des éléments différents. L’authentification par certificat prouve une clé privée sans l’envoyer, et un flux de fédération peut garder le mot de passe chez le fournisseur d’identité tout en émettant une assertion limitée vers le VPN. Ces conceptions resserrent le cercle ; aucune n’élimine toutes les parties de confiance.

Les hachages stockés protègent une autre étape

Les recommandations du NIST séparent la transmission protégée du stockage résistant du vérificateur. Le salage et un schéma de hachage coûteux traitent la menace du vérificateur stocké, c’est-à-dire ce qui se produit après coup si une base de données fuit. Ils ne font rien pour un composant d’exécution qui doit recevoir l’entrée pour la comparer. Lire ces recommandations comme si elles promettaient le secret à l’exécution est une erreur de catégorie.

Un magasin de mots de passe bien haché et un script de vérification exposé peuvent donc coexister dans un même produit sans contradiction.

Choisir une méthode qui resserre le cercle

Si l’exigence est que la passerelle ne reçoive jamais un mot de passe réutilisable, choisissez une méthode qui le garantit réellement ; changer un chiffrement de données ne crée pas cette propriété. Vérifier le certificat du serveur VPN vous dit quel pair vous avez atteint ; cela ne dit rien de la manière dont ce pair traite ensuite les identifiants. Conservez la vérification du serveur, utilisez des identifiants distincts par service et suivez le flux d’identité pris en charge par l’organisation.

Consignez la partie qui reçoit le mot de passe, la partie qui le valide et la forme sous laquelle il est conservé. Ces trois réponses vont à côté du profil de connexion, car elles survivent à tout tunnel particulier.

La question utile n’est pas de savoir si le mot de passe est chiffré, mais de qui il est caché, quel composant le reçoit et quelle forme subsiste ensuite.