Passer au contenu principal

PEAP-MSCHAPv2 : Pourquoi il est encore courant, pourquoi il est risqué et comment s'en affranchir

Un guide de référence technique complet détaillant les vulnérabilités de sécurité critiques de PEAP-MSCHAPv2, y compris les attaques de type evil twin et la capture d'identifiants. Il fournit une feuille de route pratique et neutre vis-à-vis des fournisseurs pour aider les équipes informatiques à migrer les réseaux WiFi d'entreprise vers une authentification sécurisée EAP-TLS basée sur des certificats.

📖 5 min de lecture📝 1,170 mots🔧 2 exemples concrets3 questions d'entraînement📚 8 définitions clés

Écouter ce guide

Voir la transcription du podcast
Bonjour et bienvenue dans ce point technique Purple. Je suis votre hôte, et aujourd'hui nous abordons un sujet au carrefour de l'architecture réseau, de la conformité en matière de sécurité et, pour être honnête, de la dette technique historique. Nous parlons de PEAP-MSCHAPv2. Plus précisément, nous allons voir pourquoi il reste la méthode d'authentification la plus courante pour le WiFi d'entreprise, pourquoi il est fondamentalement risqué dans le paysage des menaces actuel et, surtout, comment vous pouvez concrètement faire évoluer votre entreprise vers une solution plus performante. Commençons par le contexte. Si vous êtes directeur informatique ou architecte réseau dans un hôtel, une chaîne de magasins ou un grand espace public, il y a de fortes chances que le réseau WiFi de votre personnel — et peut-être vos appareils d'entreprise — s'authentifie à l'aide de PEAP-MSCHAPv2. C'est la norme par défaut pour les réseaux WPA2-Enterprise depuis près de deux décennies. Pourquoi ? Parce qu'il est incroyablement facile à déployer. Il se connecte directement à Active Directory via un serveur RADIUS, et les utilisateurs saisissent simplement leur nom d'utilisateur et leur mot de passe Windows habituels. Pas de certificats à gérer, pas d'infrastructure de clés publiques complexe à mettre en place. Cela fonctionne, tout simplement. Mais « fonctionner, tout simplement » ne suffit plus. L'architecture de sécurité qui sous-tend PEAP-MSCHAPv2 est, pour dire les choses crûment, obsolète. Plongeons dans la réalité technique. MSCHAPv2 repose sur l'algorithme de hachage MD4 et le chiffrement DES. Ces deux normes cryptographiques ont été conçues dans les années 1990 et sont considérées comme faibles depuis plus de dix ans. En 2012, lors de la conférence de sécurité DEF CON, le chercheur Moxie Marlinspike a démontré que la poignée de main MSCHAPv2 pouvait être déchiffrée de manière déterministe. Il a publié un outil qui réduisait le processus de décryptage à une simple clé DES unique, ce qui signifie qu'un attaquant disposant d'une puissance de calcul modeste — ou d'un accès à un service de décryptage cloud — pouvait récupérer le mot de passe Active Directory en clair d'un utilisateur à partir d'une poignée de main capturée en quelques heures, voire en quelques minutes. Alors, comment un attaquant capture-t-il concrètement cette poignée de main dans le monde réel ? Cela nous amène à l'attaque « Evil Twin ». Imaginez un bureau d'entreprise ou la zone administrative d'un hôtel. Un attaquant entre avec un point d'accès pirate — souvent un appareil aussi petit qu'un Wi-Fi Pineapple dans son sac à dos. Il configure ce point d'accès pirate pour diffuser exactement le même SSID que votre réseau d'entreprise, par exemple « Staff-WiFi ». Il augmente la puissance du signal pour que les appareils à proximité le préfèrent naturellement à vos points d'accès légitimes. Lorsqu'un ordinateur portable ou un téléphone d'un employé tente de se connecter, le point d'accès pirate joue le rôle d'authentificateur et pointe vers un faux serveur RADIUS contrôlé par l'attaquant. L'appareil de l'employé lance le tunnel PEAP. C'est là que se situe le point de défaillance critique : PEAP repose sur la vérification par l'appareil client du certificat numérique du serveur pour s'assurer qu'il communique avec le véritable serveur RADIUS de l'entreprise. Cependant, dans la grande majorité des déploiements, les appareils clients sont soit mal configurés, soit les utilisateurs voient simplement s'afficher un message contextuel leur demandant « Faites-vous confiance à ce certificat ? » et cliquent sur « Oui » uniquement pour se connecter. Une fois ce faux certificat accepté, l'appareil envoie le défi-réponse MSCHAPv2 à travers le tunnel. L'attaquant le capture, s'en va et déchiffre le hachage hors ligne. Il dispose désormais d'identifiants Active Directory valides, qu'il peut utiliser pour se connecter à votre VPN, à votre messagerie ou à tout autre service de l'entreprise. Il ne s'agit pas d'un risque théorique. C'est une procédure opérationnelle standard pour les testeurs d'intrusion comme pour les acteurs malveillants. Et si vous êtes soumis à des cadres de conformité tels que PCI DSS ou le GDPR, s'appuyer sur un protocole d'authentification compromis constitue une responsabilité majeure. Alors, si les risques sont si élevés, pourquoi n'avons-nous pas tous évolué ? La réponse réside généralement dans un mélange de complexité perçue et de matériel existant. S'affranchir de PEAP implique de passer à une authentification basée sur des certificats, plus précisément EAP-TLS. EAP-TLS est la référence absolue. Il exige que le serveur et l'appareil client présentent tous deux un certificat numérique valide. Aucun mot de passe n'est transmis, qu'il soit haché ou non. Il est totalement insensible aux attaques par dictionnaire hors ligne et hautement résistant aux attaques Evil Twin, car le client rejettera silencieusement tout faux serveur RADIUS qui ne possède pas de certificat signé par votre autorité de certification de confiance. Mais déployer EAP-TLS signifie que vous avez besoin d'une infrastructure de clés publiques, ou PKI. Vous devez disposer d'un moyen de générer des certificats et de les distribuer de manière sécurisée à chaque ordinateur portable, téléphone et tablette de votre parc. Il y a cinq ans, la mise en place d'une infrastructure Active Directory Certificate Services de Microsoft était un projet titanesque et coûteux. Aujourd'hui, cependant, le paysage a changé. La voie de mise en œuvre est beaucoup plus claire. Si vous planifiez une migration, voici l'approche pragmatique que nous recommandons à nos clients chez Purple. Tout d'abord, vous n'avez pas besoin de faire une transition brutale. Les serveurs RADIUS modernes — qu'il s'agisse de Cisco ISE, d'Aruba ClearPass ou de solutions cloud-natives — vous permettent d'exécuter PEAP-MSCHAPv2 et EAP-TLS simultanément sur le même SSID. La première étape consiste à déployer votre PKI. Vous n'avez plus nécessairement besoin de la concevoir sur site. Les solutions de PKI cloud s'intègrent directement à votre fournisseur d'identité — comme Entra ID ou Google Workspace — et à vos plateformes de gestion des appareils mobiles (MDM) comme Intune ou Jamf. La deuxième étape consiste à utiliser votre MDM pour déployer de manière transparente des certificats clients sur vos appareils gérés. Vous pouvez configurer le profil WiFi via le MDM pour qu'il privilégie EAP-TLS. Cela signifie que vos ordinateurs portables d'entreprise basculeront automatiquement vers la méthode sécurisée basée sur les certificats, sans aucune interaction de l'utilisateur. La troisième étape est la phase de transition. Vous surveillez vos journaux RADIUS. Vous verrez vos appareils gérés s'authentifier via EAP-TLS, tandis que les appareils non gérés ou plus anciens continueront d'utiliser PEAP. Cela nous amène au piège classique : les appareils existants. Que faites-vous des lecteurs de codes-barres vieux de dix ans dans votre entrepôt ou des anciens terminaux de point de vente qui ne prennent tout simplement pas en charge EAP-TLS ? La solution est la segmentation. Vous ne devez jamais dégrader la sécurité de votre réseau principal pour vous adapter au dénominateur commun le plus faible. Au lieu de cela, isolez ces anciens appareils sur un VLAN dédié. Vous pouvez utiliser l'authentification basée sur les adresses MAC combinée à des contrôles d'accès réseau stricts, garantissant que ces appareils ne peuvent communiquer qu'avec les serveurs internes spécifiques dont ils ont besoin, et absolument rien d'autre. Une fois que votre parc géré a entièrement migré vers EAP-TLS, vous pouvez enfin désactiver PEAP-MSCHAPv2 sur votre SSID d'entreprise principal, fermant ainsi définitivement la fenêtre de vulnérabilité. Faisons un rapide jeu de questions-réponses basé sur les interrogations les plus courantes des directeurs informatiques. Question un : « Le WPA3 résout-il le problème de PEAP-MSCHAPv2 ? » Réponse : Non. Le WPA3 améliore le chiffrement sur les ondes, mais la méthode d'authentification EAP sous-jacente reste la même. Si vous utilisez WPA3-Enterprise avec PEAP-MSCHAPv2, vous êtes toujours vulnérable à la capture d'identifiants via un Evil Twin si le client ne valide pas strictement le certificat du serveur. Question deux : « Qu'en est-il d'EAP-TTLS ? » Réponse : EAP-TTLS est préférable à PEAP car il隧道 l'authentification, utilisant souvent PAP au lieu de MSCHAPv2, ce qui évite les faiblesses cryptographiques spécifiques de MSCHAPv2. Cependant, il repose toujours sur des mots de passe et reste vulnérable si le certificat du serveur n'est pas validé. C'est une étape intermédiaire, mais EAP-TLS doit être l'objectif final. Question trois : « Quel est l'impact sur notre WiFi invité Purple ? » Réponse : Aucun impact direct. Le WiFi invité utilise généralement des réseaux ouverts avec des portails captifs ou du WPA2/3-Personal, qui sont distincts de votre authentification d'entreprise 802.1X. Cependant, la sécurisation de votre réseau administratif et technique est essentielle pour protéger l'infrastructure qui prend en charge toutes les opérations de votre site, y compris vos services invités et vos plateformes d'analyse. Pour résumer : PEAP-MSCHAPv2 nous a bien servi, mais son temps est révolu. Les failles cryptographiques sont publiques et les outils d'attaque sont automatisés. La migration vers EAP-TLS n'est plus un projet d'avant-garde ; c'est une mise à niveau standard et réalisable, grandement facilitée par les solutions MDM et PKI cloud modernes. Le risque de ne rien faire — un mot de passe Active Directory compromis entraînant une violation plus large du réseau — l'emporte de loin sur l'effort opérationnel de la migration. Commencez dès aujourd'hui par un audit de vos journaux RADIUS, identifiez vos appareils obsolètes et commencez à planifier votre transition vers l'authentification basée sur des certificats. Merci d'avoir écouté ce point technique Purple. Pour des guides de déploiement plus détaillés et des schémas d'architecture, n'hésitez pas à lire le guide de référence technique complet qui accompagne ce podcast.

header_image.png

Synthèse

Malgré des vulnérabilités cryptographiques largement documentées, PEAP-MSCHAPv2 reste la méthode EAP la plus déployée pour l'authentification WiFi d'entreprise dans les secteurs de l'hôtellerie, du commerce de détail et du secteur public. Sa prévalence continue s'explique par sa facilité de déploiement — en particulier son intégration native avec Active Directory — plutôt que par son efficacité en matière de sécurité. Cependant, le profil de risque a radicalement changé. Des outils d'exploitation automatisés ont démocratisé l'attaque de type « evil twin », permettant à des acteurs malveillants de capturer et de casser les hachages de défi-réponse MSCHAPv2 avec un effort dérisoire, ce qui conduit directement à la compromission des identifiants Active Directory.

Pour les directeurs informatiques et les architectes réseau, le mandat est clair : PEAP-MSCHAPv2 n'est plus adapté à aucun environnement soumis à des cadres de conformité tels que PCI DSS ou le GDPR. Ce guide propose une analyse critique des vecteurs d'attaque spécifiques ciblant PEAP-MSCHAPv2 et présente un plan de migration pragmatique et progressif vers EAP-TLS. En s'appuyant sur les solutions modernes de gestion des appareils mobiles (MDM) et d'infrastructure à clés publiques (PKI) cloud, les organisations peuvent passer à une authentification robuste basée sur des certificats sans perturber les opérations commerciales ni exclure les appareils existants.

Analyse technique approfondie : L'anatomie de la vulnérabilité

Pour comprendre pourquoi PEAP-MSCHAPv2 doit être abandonné, il faut examiner son architecture cryptographique sous-jacente. MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2) a été conçu à la fin des années 1990 et s'appuie sur l'algorithme de hachage MD4 et le standard de chiffrement Data Encryption Standard (DES) [1]. Tous deux sont considérés comme obsolètes selon les normes cryptographiques modernes.

La faille cryptographique

La faiblesse fondamentale réside dans la manière dont MSCHAPv2 gère le hachage NT du mot de passe de l'utilisateur. Le protocole divise une clé de 21 octets dérivée du hachage NT en trois clés DES de 7 octets. De manière cruciale, la troisième clé n'utilise que deux octets significatifs du hachage, complétant le reste avec des octets nuls. Cette faille structurelle réduit la complexité cryptographique de manière exponentielle.

En 2012, le chercheur en sécurité Moxie Marlinspike a démontré que la liaison MSCHAPv2 pouvait être cassée de manière déterministe en ramenant le problème au cassage d'une seule clé DES [2]. En utilisant des services de cassage basés sur le cloud ou des configurations GPU modernes exécutant des outils comme hashcat, un attaquant peut récupérer le mot de passe Active Directory en clair à partir d'une liaison capturée en quelques heures, quelle que soit la complexité du mot de passe.

Le vecteur d'attaque « Evil Twin »

La faiblesse cryptographique est exploitée dans la nature via l'attaque « evil twin ». Dans un scénario typique au sein d'un bureau d'entreprise ou d'un établissement de l' Hôtellerie :

  1. Déploiement d'un point d'accès pirate : L'attaquant déploie un point d'accès pirate diffusant le SSID de l'entreprise cible (par exemple, « Staff-WiFi »).
  2. Dominance du signal : Le point d'accès pirate fonctionne à une puissance d'émission plus élevée, obligeant les appareils clients à proximité à s'y associer plutôt qu'à l'infrastructure légitime.
  3. Fausse authentification RADIUS : Lorsque le client initie le tunnel PEAP, le point d'accès pirate relaie la demande vers un serveur RADIUS contrôlé par l'attaquant (tel que hostapd-wpe).
  4. Échec de la validation du certificat : Le serveur RADIUS pirate présente un certificat numérique auto-signé ou non vérifié. Si l'appareil client est mal configuré pour contourner la validation stricte du certificat du serveur — ou si l'utilisateur clique simplement sur « Accepter » lors d'une invite de confiance —, le tunnel est établi.
  5. Capture des identifiants : Le client transmet le défi-réponse MSCHAPv2 via le tunnel compromis. L'attaquant capture le hachage et met fin à la connexion.

evil_twin_attack_diagram.png

Sans une validation stricte du certificat du serveur appliquée au niveau du terminal, chaque appareil utilisant PEAP-MSCHAPv2 est vulnérable à cette technique de capture d'identifiants. Cela est particulièrement préoccupant pour les environnements du Commerce de détail où les réseaux d'arrière-boutique partagent souvent une proximité physique avec les espaces publics.

Guide de mise en œuvre : Migration vers EAP-TLS

La solution définitive aux vulnérabilités de MSCHAPv2 est la migration vers EAP-TLS (Extensible Authentication Protocol-Transport Layer Security). EAP-TLS impose une authentification mutuelle : le serveur RADIUS et l'appareil client doivent tous deux présenter des certificats numériques valides. Comme aucun mot de passe n'est transmis ou haché pendant la liaison, EAP-TLS est entièrement immunisé contre les attaques par dictionnaire hors ligne et hautement résistant à l'usurpation par « evil twin ».

Historiquement, le principal obstacle à l'adoption d'EAP-TLS était la complexité du déploiement d'une infrastructure à clés publiques (PKI) sur site. Aujourd'hui, la PKI cloud et les intégrations MDM modernes ont simplifié le processus.

Étape 1 : Audit et inventaire

Avant de modifier les politiques d'authentification, effectuez un audit complet de vos journaux RADIUS actuels (par exemple, Cisco ISE, Aruba ClearPass ou Windows NPS). Identifiez tous les appareils s'authentifiant actuellement via PEAP. Catégorisez ces appareils en deux groupes :

  • Appareils gérés : Ordinateurs portables, tablettes et smartphones d'entreprise enregistrés dans une plateforme MDM (par exemple, Intune, Jamf).
  • Appareils non gérés/existants : Capteurs IoT, terminaux de point de vente plus anciens, lecteurs de codes-barres ou appareils BYOD qui ne peuvent pas prendre en charge l'enregistrement de certificats.

Étape 2 : Déploiement de la PKI et configuration RADIUS

Déployez une solution PKI pour émettre des certificats clients et serveurs. Les plateformes PKI cloud natives peuvent s'intégrer directement avec Entra ID ou Google Workspace, éliminant ainsi le besoin d'une infrastructure lourde sur sitee l'empreinte Microsoft AD CS. Configurez votre serveur RADIUS pour accepter l'authentification EAP-TLS. Surtout, configurez la politique réseau pour prendre en charge simultanément PEAP et EAP-TLS sur le même SSID pendant la période de transition.

eap_comparison_chart.png

Phase 3 : Distribution des certificats via MDM

Exploitez votre plateforme MDM pour distribuer de manière transparente les certificats clients aux appareils gérés en utilisant des protocoles tels que SCEP (Simple Certificate Enrollment Protocol). Parallèlement, déployez une charge utile de profil WiFi mise à jour via le MDM qui indique aux appareils de donner la priorité à EAP-TLS pour le SSID de l'entreprise. Cela garantit une transition sans intervention pour les utilisateurs finaux.

Phase 4 : Gestion des appareils hérités

Les appareils hérités qui ne peuvent pas prendre en charge EAP-TLS ne doivent jamais dicter la posture de sécurité du réseau d'entreprise principal. Au lieu de cela, segmentez ces appareils sur un VLAN dédié. Implémentez le contournement d'authentification basé sur l'adresse MAC (MAB) combiné à des listes de contrôle d'accès (ACL) strictes pour garantir que ces appareils ne peuvent communiquer qu'avec les serveurs internes spécifiques requis pour leur fonctionnement.

migration_roadmap.png

Bonnes pratiques et conformité

Le maintien d'un environnement sans fil d'entreprise sécurisé nécessite une adhésion continue aux normes de l'industrie.

  • Imposer la validation du certificat du serveur : Si vous devez temporairement conserver PEAP-MSCHAPv2, utilisez le MDM pour imposer un épinglage strict du certificat du serveur sur tous les points de terminaison. Empêchez les utilisateurs d'approuver manuellement des certificats inconnus.
  • Déprécier le WPA2-Personal : Assurez-vous que tous les accès d'entreprise reposent sur le 802.1X (WPA2/WPA3-Enterprise). Les clés pré-partagées (PSK) doivent être strictement limitées aux réseaux IoT isolés.
  • S'aligner sur la norme PCI DSS : Pour les établissements traitant des paiements, la condition 4 de la norme PCI DSS impose une cryptographie forte pour la transmission des données des titulaires de cartes sur les réseaux sans fil. Le PCI Security Standards Council recommande explicitement EAP-TLS pour une authentification robuste [3].
  • Surveiller les analyses : Utilisez des plateformes telles que WiFi Analytics de Purple pour surveiller la santé du réseau, identifier les schémas de connexion anormaux et vous assurer que les appareils hérités ne tentent pas d'accéder à des sous-réseaux restreints.

ROI et impact commercial

Le retour sur investissement de la migration vers EAP-TLS se mesure principalement par l'atténuation des risques. Une attaque de type « evil twin » réussie contre PEAP-MSCHAPv2 permet d'obtenir des identifiants Active Directory valides, offrant ainsi aux acteurs malveillants un accès initial au réseau de l'entreprise. L'impact financier d'une violation de données, d'un déploiement de ransomware ou d'une amende réglementaire (comme dans le cadre du GDPR) qui en découlerait dépasse largement le coût opérationnel du déploiement d'une PKI cloud et de la mise à jour des profils MDM.

De plus, l'authentification basée sur les certificats réduit considérablement le volume de tickets d'assistance liés à l'expiration et au blocage des mots de passe. En passant à EAP-TLS, les équipes informatiques éliminent les frictions liées à l'accès WiFi par mot de passe, offrant ainsi une expérience de connectivité fluide et sécurisée qui prend en charge les architectures réseau modernes de type zero-trust.

Références

[1] Microsoft Security Response Center. « Weaknesses in MS-CHAPv2 authentication. » Août 2012. [2] Marlinspike, Moxie. « Defeating PPTP VPNs and WPA2 Enterprise with MS-CHAPv2. » DEF CON 20, 2012. [3] PCI Security Standards Council. « Information Supplement: PCI DSS Wireless Guidelines. »

Définitions clés

PEAP (Protected Extensible Authentication Protocol)

Une méthode EAP qui encapsule le processus d'authentification dans un tunnel TLS sécurisé pour protéger les identifiants d'authentification internes contre l'interception sur les ondes.

Largement utilisé car il ne nécessite qu'un certificat côté serveur, ce qui le rend plus facile à déployer que les méthodes d'authentification mutuelle.

MSCHAPv2

Le protocole d'authentification interne couramment utilisé dans un tunnel PEAP, qui repose sur un mécanisme de défi-réponse utilisant le hachage NT du mot de passe de l'utilisateur.

La principale source de vulnérabilité dans les déploiements PEAP en raison de sa dépendance à l'égard du hachage MD4 et du chiffrement DES obsolètes.

EAP-TLS

Une méthode EAP nécessitant une authentification mutuelle, dans laquelle le serveur RADIUS et l'appareil client présentent tous deux des certificats numériques pour prouver leur identité.

La référence absolue du secteur pour la sécurité WiFi d'entreprise, insensible aux attaques par dictionnaire hors ligne et aux attaques evil twin.

Evil Twin Attack

Une attaque sans fil dans laquelle un point d'accès pirate imite un SSID d'entreprise légitime pour inciter les appareils clients à s'y connecter, permettant ainsi à l'attaquant d'intercepter le trafic ou de capturer des identifiants d'authentification.

Le principal vecteur utilisé par les attaquants pour capturer les poignées de main MSCHAPv2 à partir de déploiements PEAP vulnérables.

RADIUS (Remote Authentication Dial-In User Service)

Un protocole réseau qui fournit une gestion centralisée de l'authentification, de l'autorisation et de la comptabilité (AAA) pour les utilisateurs qui se connectent et utilisent un service réseau.

L'infrastructure de serveur centrale (comme Cisco ISE ou NPS) qui traite les demandes d'authentification 802.1X provenant des points d'accès.

PKI (Public Key Infrastructure)

Un ensemble de rôles, de politiques, de matériels, de logiciels et de procédures nécessaires pour créer, gérer, distribuer, utiliser, stocker et révoquer des certificats numériques.

L'infrastructure fondamentale requise pour déployer EAP-TLS, de plus en plus fournie via des plateformes SaaS cloud-natives.

MDM (Mobile Device Management)

Logiciel qui permet aux administrateurs informatiques de contrôler, sécuriser et appliquer des politiques sur les smartphones, les tablettes et les terminaux.

Essentiel pour les migrations EAP-TLS, car il est utilisé pour déployer de manière transparente des certificats clients et des profils WiFi stricts sur les appareils de l'entreprise.

MAB (MAC Authentication Bypass)

Une méthode de contrôle d'accès basée sur les ports qui authentifie les appareils en fonction de leur adresse MAC plutôt que de requérir un nom d'utilisateur/mot de passe ou un certificat.

Utilisé comme mécanisme de secours pour authentifier les appareils existants sans interface utilisateur (comme les imprimantes) qui ne peuvent pas prendre en charge les protocoles 802.1X.

Exemples concrets

Une chaîne hôtelière de 400 chambres utilise actuellement PEAP-MSCHAPv2 pour le réseau de son personnel administratif et technique. Le directeur informatique souhaite migrer vers EAP-TLS mais s'inquiète pour 50 terminaux d'inventaire portables existants qui fonctionnent sous un système d'exploitation obsolète et ne prennent pas en charge l'enregistrement de certificats. Comment l'architecte réseau doit-il gérer cette migration sans interrompre les opérations d'inventaire ?

L'architecte réseau doit mettre en œuvre une approche segmentée. Tout d'abord, déployez une PKI cloud et configurez le serveur RADIUS central pour qu'il accepte à la fois EAP-TLS et PEAP-MSCHAPv2. Utilisez la plateforme MDM de l'hôtel pour déployer les certificats clients et un profil WiFi EAP-TLS mis à jour sur tous les ordinateurs portables et tablettes modernes du personnel. Pour les 50 terminaux obsolètes, créez un SSID masqué dédié, associé à un VLAN isolé. Configurez le contournement d'authentification MAC (MAB) pour les adresses MAC de ces terminaux spécifiques sur le serveur RADIUS. Appliquez des ACL réseau strictes à ce VLAN afin que les terminaux ne puissent accéder qu'au serveur de la base de données d'inventaire et à rien d'autre. Une fois que tous les appareils modernes utilisent EAP-TLS, désactivez PEAP-MSCHAPv2 sur le réseau principal du personnel.

Commentaire de l'examinateur : Cette approche équilibre parfaitement une sécurité robuste pour la majorité du parc avec la continuité opérationnelle du matériel existant. En isolant les anciens appareils sur un VLAN restreint, l'architecte atténue le risque que ces appareils soient utilisés comme point de pivot en cas de compromission, tout en éliminant avec succès la vulnérabilité PEAP-MSCHAPv2 du réseau d'entreprise principal.

Une entreprise de vente au détail a déployé Windows 11 22H2 sur son parc informatique. Le centre d'assistance informatique reçoit soudainement des tickets indiquant que les utilisateurs ne peuvent pas se connecter au réseau WiFi d'entreprise WPA2-Enterprise, qui utilise PEAP-MSCHAPv2. Quelle est la cause probable et quelle est la solution immédiate ?

La cause probable est l'introduction de Windows Defender Credential Guard, qui est activé par défaut dans Windows 11 22H2 et les versions ultérieures. Credential Guard isole et protège les hachages de mots de passe NTLM et les tickets Kerberos (TGT). Comme PEAP-MSCHAPv2 nécessite l'accès au hachage NT pour générer le défi-réponse, Credential Guard bloque intentionnellement cette méthode d'authentification pour empêcher le vol d'identifiants. La solution immédiate consiste à accélérer la migration vers EAP-TLS, qui utilise une authentification basée sur des certificats et est entièrement compatible avec Credential Guard. Une solution de contournement temporaire et moins sécurisée consisterait à désactiver Credential Guard via une stratégie de groupe, mais cela est fortement déconseillé car cela affaiblit la posture de sécurité globale du système d'exploitation.

Commentaire de l'examinateur : Ce scénario met en évidence un moteur opérationnel moderne et critique pour abandonner PEAP. Les propres améliorations de sécurité du système d'exploitation de Microsoft désactivent activement l'accès aux hachages hérités requis par MSCHAPv2. La solution identifie correctement EAP-TLS comme le correctif permanent plutôt que de s'appuyer sur des rétrogradations non sécurisées du système d'exploitation.

Questions d'entraînement

Q1. Vous auditez le réseau sans fil d'une filiale nouvellement acquise. Ils utilisent PEAP-MSCHAPv2. Le responsable informatique affirme qu'ils sont protégés contre les attaques evil twin car ils ont masqué le SSID et désactivé sa diffusion. Leur réseau est-il à l'abri de la capture d'identifiants ?

Conseil : Réfléchissez au comportement des appareils clients lorsqu'ils sont configurés pour se connecter à des réseaux masqués, et si le masquage d'un SSID empêche un point d'accès pirate de l'usurper.

Voir la réponse type

Non, le réseau n'est pas sécurisé. Masquer le SSID (désactiver les trames de balise) n'apporte aucune sécurité cryptographique. En réalité, les appareils configurés pour se connecter à des réseaux masqués diffusent activement des requêtes de sonde contenant le nom du SSID, annonçant ainsi le réseau masqué à tout attaquant à l'écoute. Un attaquant peut facilement capturer le nom du SSID, configurer un point d'accès evil twin diffusant ce SSID exact et exécuter l'attaque standard de capture d'identifiants MSCHAPv2. La seule défense est une validation stricte du certificat du serveur ou la migration vers EAP-TLS.

Q2. Lors d'un pilote de migration EAP-TLS, vous déployez des certificats clients sur 20 ordinateurs portables Windows via Intune. Cependant, l'authentification échoue pour les 20 appareils. Les journaux du serveur RADIUS indiquent « Certificat client non approuvé ». Les certificats clients ont été émis par votre nouvelle PKI cloud. Quelle étape de configuration critique a été manquée ?

Conseil : Pour que l'authentification mutuelle fonctionne, les deux parties doivent faire confiance à l'entité qui a émis le certificat de l'autre partie.

Voir la réponse type

Le serveur RADIUS n'a pas été configuré pour faire confiance à l'autorité de certification racine (Root CA) de la nouvelle PKI cloud. Bien que les ordinateurs portables disposent des certificats clients appropriés, lorsqu'ils les présentent au serveur RADIUS, celui-ci les rejette car il ne possède pas les certificats racine/intermédiaires de la PKI cloud dans son magasin de confiance local. Vous devez importer le certificat public de l'autorité de certification racine de la PKI cloud dans le magasin d'autorités de certification de confiance du serveur RADIUS.

Q3. Votre entreprise impose EAP-TLS pour le WiFi d'entreprise. Un cadre dirigeant insiste pour connecter son iPad personnel et non géré au réseau de l'entreprise afin d'accéder aux tableaux de bord financiers internes. Comment répondez-vous à cette demande tout en maintenant la posture de sécurité EAP-TLS ?

Conseil : Prenez en compte les prérequis pour EAP-TLS et la définition d'un appareil « géré ».

Voir la réponse type

Vous ne pouvez pas répondre de manière sécurisée à cette demande sur le réseau d'entreprise principal sans compromettre l'architecture EAP-TLS. EAP-TLS nécessite un certificat client. L'iPad n'étant pas géré (BYOD), le service informatique ne peut pas déployer de certificat de manière sécurisée via un MDM. Permettre au cadre d'installer manuellement un certificat introduit un risque important et une charge administrative lourde. La bonne approche consiste à refuser l'accès au SSID de l'entreprise. À la place, le cadre doit se connecter au WiFi invité et utiliser un VPN d'entreprise sécurisé (prenant en charge l'authentification moderne MFA/SAML) pour accéder aux ressources internes, ou l'appareil doit être enregistré dans le MDM de l'entreprise pour recevoir un certificat.

Continuer la lecture de cette série

Comment configurer SCEP pour l'enrôlement automatisé de certificats WiFi d'entreprise

Ce guide explique comment configurer SCEP (Simple Certificate Enrollment Protocol) pour l'enrôlement automatisé de certificats WiFi d'entreprise, couvrant l'architecture complète depuis la PKI et le NDES jusqu'au déploiement de profils MDM et à la validation RADIUS. Il s'adresse aux responsables informatiques, architectes réseau et CTO d'hôtels, de chaînes de vente au détail, de stades, de centres de conférence et d'organisations du secteur public qui souhaitent dépasser les clés pré-partagées et mettre en œuvre une authentification 802.1X EAP-TLS évolutive et basée sur l'identité. La plateforme cloud overlay de Purple, indépendante du matériel, s'intègre directement à cette architecture, fournissant la couche WiFi pour les invités et le BYOD qui coexiste avec votre réseau d'employés authentifié par certificat.

Lire le guide →

Le guide de l'entreprise pour SCEP : Déployer le protocole SCEP (Simple Certificate Enrollment Protocol) pour la sécurité automatisée du WiFi sur les campus

Ce guide de référence technique fournit un schéma d'architecture définitif et une stratégie d'implémentation étape par étape pour le déploiement de certificats WiFi d'entreprise à l'aide de SCEP. Il présente les différences cruciales entre SCEP et PKCS, la séquence de déploiement exacte requise pour réussir, ainsi que des stratégies concrètes de mitigation des risques pour les responsables informatiques.

Lire le guide →

Comment implémenter SCEP pour l'enrôlement automatisé de certificats WiFi

Ce guide explique comment implémenter SCEP (Simple Certificate Enrollment Protocol) pour l'enrôlement automatisé de certificats WiFi dans les établissements d'entreprise. Il couvre l'ensemble du schéma architectural - de la conception de la PKI et l'intégration MDM à la séquence de déploiement obligatoire en trois étapes - et montre aux responsables informatiques et architectes réseau comment éliminer les identifiants partagés, automatiser la gestion du cycle de vie des certificats et respecter les exigences PCI DSS et GDPR à grande échelle.

Lire le guide →
PEAP-MSCHAPv2 : Pourquoi il est encore courant, pourquoi il est risqué et comment s'en affranchir | Guides techniques | Purple