D'abord la méthode EAP : quel hachage de mot de passe un VPN peut utiliser
Un VPN vérifie le secret, pas le hachage web. Lisez la méthode, puis vérifiez ce que contient le magasin avant de promettre que les mêmes mots de passe continueront de fonctionner.
Beaucoup d'équipes ont une connexion web qui fonctionne et un VPN qui refuse chaque mot de passe de la même table. L'application web compare un hachage qu'elle a calculé elle-même, tandis que le tunnel demande au client de prouver la possession d'un secret d'une manière que le serveur doit pouvoir vérifier. Ce sont des exigences différentes sur le matériau stocké. C'est dans l'écart entre les deux que la plupart de ces projets s'enlisent.
Lisez la méthode, puis le schéma
Notez la preuve qu'exige la méthode retenue avant de regarder le moindre schéma. Une méthode défi-réponse a besoin d'un matériau à partir duquel le serveur peut calculer la réponse attendue, ce qui signifie en pratique le mot de passe ou une forme dérivée compatible. Une méthode qui transporte le mot de passe dans un tunnel protégé a besoin du mot de passe lui-même chez le vérificateur. Lisez la documentation de la méthode pour l'exigence du vérificateur et non pour la configuration du client, car les exigences du client sont généralement la partie facile.
Un hachage salé produit par un framework web moderne ne fournit ni l'un ni l'autre. Il vérifie une comparaison précise et ne peut pas être ramené au secret dont il provient.
Le défi-réponse ne peut pas utiliser un hachage salé
MSCHAPv2 est un échange défi-réponse, le serveur ne reçoit donc jamais le mot de passe et ne peut pas comparer une chaîne stockée. Il doit dériver la réponse attendue d'un matériau qu'il détient déjà, et c'est pourquoi les formes stockées compatibles sont si étroites. Une valeur bcrypt ou Argon2 avec un sel par utilisateur est à sens unique d'une manière qui exclut entièrement l'échange. Le tableau ci-dessous part de la forme de stockage plutôt que du nom de la méthode, car c'est la forme de stockage qui décide de la réponse.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
La documentation du greffon SQL pour strongSwan définit son propre schéma pour la configuration et les identifiants, et le projet marque toujours ce greffon comme expérimental. Rien n'y s'adapte à la table des utilisateurs d'une application ni ne devine quel schéma de hachage a produit une valeur stockée. Les options réalistes sont donc une migration vers un magasin que la passerelle peut utiliser, ou un service d'authentification devant le magasin existant qui peut effectuer l'échange. Tout le reste est un connecteur avec une hypothèse cachée à l'intérieur.
RADIUS déplace le travail, pas l'exigence
Déléguer EAP à un serveur RADIUS change l'endroit où la vérification a lieu et améliore généralement la piste d'audit. Cela ne récupère pas un mot de passe à partir d'un hachage à sens unique, donc le service d'authentification a toujours besoin d'un matériau compatible avec la méthode qu'il termine. Les équipes le découvrent après avoir construit le chemin RADIUS et rencontré le même mur à l'autre bout.
Là où le serveur RADIUS peut lire un annuaire contenant un identifiant compatible, la conception fonctionne et la passerelle VPN reste simple. Là où il ne peut pas, la réponse honnête est un changement d'inscription plutôt qu'un connecteur de plus. Le provisionnement et la révocation appartiennent à celui qui possède l'identité, donc une table copiée sans processus de synchronisation pris en charge est un second cycle de vie des identifiants plutôt qu'une authentification unique. Elle dérive la première fois que quelqu'un réinitialise un mot de passe à un seul endroit, et la dérive reste silencieuse jusqu'à ce qu'un compte présent dans les deux systèmes se comporte différemment dans chacun.
Limitez le compte qui lit l'annuaire à cette lecture, et gardez-le séparé du compte que la passerelle utilise pour sa propre configuration. Un compte administratif partagé transforme une conception en lecture seule en un rayon d'impact bien plus large.
Où le compte doit vivre
Une fois la question du matériau réglée, deux architectures subsistent. La passerelle peut posséder un petit magasin d'identifiants qu'elle seule lit, ou déléguer à un service d'authentification qui se place devant l'annuaire de l'entreprise.
La première est plus facile à raisonner et moins bonne pour l'utilisateur, qui finit avec un second mot de passe à maintenir. La seconde conserve une seule identité et ajoute une dépendance à un service qui doit désormais être disponible avant que quiconque puisse se connecter. Aucune n'est fausse, mais le choix devrait être consigné à côté de la configuration de la passerelle, sinon l'ingénieur suivant supposera que l'autre a été retenue. Quel que soit votre choix, les deux commandes ci-dessous sont celles qui montrent l'état actuel avant que vous ne le changiez.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsL'authentification du compte ne règle pas non plus l'autorisation. L'appartenance à un groupe, l'état de l'appareil et l'autorisation réseau nécessitent encore une correspondance explicite une fois que l'utilisateur a prouvé l'identité requise. Une connexion qui s'authentifie parfaitement et n'autorise rien est un résultat de politique, pas un défaut de la méthode.