Exporter les profils Wi‑Fi (y compris les mots de passe) de la bonne façon

Ce que vous exportez réellement (et pourquoi c’est sensible)

Un « profil Wi‑Fi » n’est pas seulement un SSID et un mot de passe. C’est un paquet de préférences de connexion et de paramètres de sécurité qui peut inclure :

• SSID et parfois des indicateurs de réseau masqué
• Type de sécurité (WPA2/WPA3, 802.1X en entreprise, etc.)
• La clé pré‑partagée (PSK) pour les réseaux WPA‑Personal
• Méthodes EAP, indices d’identité, identités anonymes et paramètres de domaine
• Certificats, clés privées et autorités de confiance (surtout en environnement entreprise)
• Priorité d’auto‑connexion, drapeaux mesurés, configuration proxy, surcharges DNS
• Paramètres de randomisation MAC et contrôles de confidentialité par réseau

Exporter un profil « avec mot de passe » signifie souvent écrire des secrets dans un fichier. Ce fichier devient un artefact d’identification que vous devez contrôler comme une clé SSH privée ou un dump de mot de passe de base de données. Si vous ne pouvez pas dire où il vivra, qui peut le lire et quand il sera détruit, vous n’exportez pas — vous renversez.

Voici une règle pratique : si l’export contient une clé qui permet de s’authentifier, traitez‑la comme un secret de production. Les secrets de production n’ont pas leur place dans les e‑mails. Ils n’ont pas leur place dans les chats. Ils n’ont pas leur place dans les captures d’écran. Ils doivent transiter via une méthode contrôlée, avoir une durée de vie courte et un propriétaire clairement identifié.

Faits et historique qui changent votre regard sur les exports Wi‑Fi

1. WEP a été normalisé à la fin des années 1990 et était tellement cassé que « exporter une clé Wi‑Fi » était le moindre de vos soucis. Les exports modernes sont plus dangereux parce que la crypto est meilleure, donc la clé compte davantage.
2. WPA2 est arrivé au milieu des années 2000 et a rendu les PSK courants. C’est pourquoi les « mots de passe Wi‑Fi enregistrés » sont devenus une préoccupation de migration d’ordinateurs portables plutôt qu’un détail de sécurité mineur.
3. Le Wi‑Fi d’entreprise 802.1X précède beaucoup de fonctions grand public. De nombreux réseaux corporatifs utilisent EAP‑TLS ou PEAP avec certificats, ce qui change la nature même de ce que signifie « exporter ».
4. Windows offre depuis longtemps l’export de profils Wi‑Fi via netsh, mais l’option « clear key » est un couteau tranchant : simple, rapide et absolument pas auto‑sanitissante.
5. macOS stocke les secrets Wi‑Fi dans Keychain avec des contrôles d’accès. L’export est moins « vider un fichier » et plus « récupérer avec le consentement de l’utilisateur », ce qui est agaçant jusqu’à ce que vous nettoyiez une fuite.
6. Linux divise l’histoire : NetworkManager stocke des profils de connexion en fichiers, mais le stockage des secrets peut reposer sur un keyring ou sur des fichiers selon la configuration.
7. Les listes de roaming Wi‑Fi peuvent devenir une surface d’attaque. Les appareils qui se connectent automatiquement aux SSID connus peuvent être appâtés par des evil twins. Exporter et importer des profils peut involontairement élargir cette liste.
8. WPA3 et les Protected Management Frames aident, mais rien de tout cela n’a d’importance si la PSK est copiée dans un dossier lisible par tous et synchronisée sur cinq appareils.

Modèle de menace : qui pourrait abuser de vos profils exportés

Il ne faut pas un hacker hollywoodien. Il suffit d’une personne ennuyée ayant accès en lecture au mauvais répertoire, ou d’un portable revendu sans effacement complet. Pensez à ces modes de défaillance :

1) La menace du « collègue serviable »

Vous exportez des profils sur un lecteur partagé pour que l’utilisateur les récupère plus tard. Une autre équipe voit « wifi‑backup » et le télécharge « pour plus tard », parce que les humains collectionnent les fichiers comme des écureuils accumulent des regrets.

2) La menace du « client de sync »

Tout ce qui se trouve dans Desktop/Documents/Downloads peut être synchronisé vers un compte cloud grand public. Félicitations : vous venez de distribuer la PSK du bureau à un service tiers avec une rétention inconnue.

3) La menace de la « transcription de support »

Quelqu’un colle la PSK dans le chat « juste une seconde ». Cette « seconde » est conservée pour toujours dans les logs, exports, sauvegardes, procédures légales et captures d’écran.

4) La quête secondaire de l’« evil twin »

Importer des profils en masse peut pousser des appareils à se connecter automatiquement à des SSID qu’ils ne devraient pas. Les attaquants peuvent installer des SSID ressemblants, surtout pour des noms courants comme « Guest » ou « CompanyWiFi ».

Une citation à garder en tête, parce qu’elle décrit tout le problème d’export :
Espérer n’est pas une stratégie. — Gene Kranz

Si votre plan d’export repose sur l’espoir que personne ne copie le fichier, que le fichier ne synchronise pas, ou que le mot de passe n’est pas réutilisé ailleurs, vous êtes dans le business du « rapport après incident ».

Windows : exporter les profils de façon sensée

Sur Windows, vous pouvez énumérer et exporter les profils WLAN avec netsh. Vous pouvez aussi extraire la clé d’un profil. C’est à la fois une fonctionnalité et un piège.

Ce que fait réellement « export avec clear key »

L’export génère un XML par profil. Avec key=clear, la PSK apparaît en clair dans le XML. Cela facilite l’import. Ça transforme aussi le fichier en déchet toxique : lisible égale utilisable.

Approche minimale sûre

• N’exportez que le profil dont vous avez besoin, pas « tous les profils ».
• Exportez vers un répertoire contrôlé avec des ACL restreintes.
• Transférez via un canal sécurisé approuvé (ou un média hors ligne sous contrôle).
• Supprimez le fichier d’export de façon sécurisée dès que possible (et sachez ce que « sécurisé » signifie sur votre système de fichiers).
• Préférez le provisioning d’entreprise (MDM/GPO) pour les réseaux corporatifs plutôt que les exports manuels.

Blague n°1 : Exporter les profils Wi‑Fi sur votre bureau revient à cacher des clés sous le paillasson — pratique jusqu’à ce que vous réalisiez que les cambrioleurs connaissent aussi les paillassons.

macOS : Keychain, profils et la voie sans drame

macOS ne vous incite pas à « tout vider en XML ». Il stocke les identifiants Wi‑Fi dans Keychain, et vous récupérez généralement les mots de passe par SSID avec autorisation utilisateur.

Ce que macOS fait bien

• Conserver les secrets dans Keychain avec des contrôles d’accès
• Vous obliger à prouver que vous pouvez lire le secret (invite de mot de passe/Touch ID)
• Gérer le Wi‑Fi d’entreprise via des profils de configuration (MDM), qui est la bonne méthode à grande échelle

Ce que macOS fait mal (par conception)

L’export en masse d’une pile de mots de passe Wi‑Fi. Ce n’est pas un bug ; la plateforme vous pousse à éviter la création de « dumps de secrets ». Si vous devez vraiment migrer en masse, utilisez des profils MDM. Si vous avez besoin d’une récupération ponctuelle, utilisez les outils Keychain et documentez la manipulation.

Linux : NetworkManager, wpa_supplicant et la réalité

Linux est honnête : la configuration Wi‑Fi est souvent juste des fichiers. Parfois ces fichiers contiennent des secrets dans un format qui n’est « sécurisé » que parce que les permissions de fichier sont correctes. C’est bien sur un système bien géré. C’est catastrophique sur une station de travail avec des permissions négligées et trop de copies « temporaires ».

Deux schémas de stockage courants

• NetworkManager system connections stockées sous /etc/NetworkManager/system-connections/ (souvent propriété root et permissionnées).
• wpa_supplicant configs (par ex. /etc/wpa_supplicant/wpa_supplicant.conf) qui peuvent contenir des PSK ou des identifiants EAP.

La « bonne façon » sur Linux est généralement : exporter un seul fichier de connexion avec des permissions strictes, transférer par un canal sécurisé, importer avec nmcli, puis supprimer l’artefact. Si vous faites cela de façon répétée, automatisez et intégrez des garde‑fous.

Considérations entreprise : 802.1X, certificats et MDM

Le Wi‑Fi corporate est souvent 802.1X. Cela signifie que le « mot de passe » peut être :

• un mot de passe utilisateur (mauvais pour les exports, car personnel et changeant)
• un mot de passe appareil (toujours pas idéal, mais parfois utilisé)
• un certificat client + clé privée (là vous transportez une identité pouvant usurper un appareil)

Si c’est basé sur un certificat, exporter un « profil Wi‑Fi » peut vouloir dire exporter une clé privée. Traitez‑la comme une clé SSH qui donne accès au réseau — parce que c’en est une.

Conseils orientés

• Si vous gérez des appareils : utilisez MDM (macOS) ou GPO/Intune (Windows) ou vos outils de flotte Linux. N’exportez pas manuellement des secrets sauf en cas de procédure d’urgence.
• Si vous ne gérez pas les appareils : ne récupérez la PSK que si la politique l’autorise, puis changez la PSK après la migration si elle protège quelque chose d’important.
• N’exportez pas « tous les profils » depuis un portable qui a voyagé dans des aéroports, hôtels et sites clients. Cette liste est du risque en pagaille.

Tâches pratiques : commandes, sorties et décisions (12+)

Cette section est volontairement opérationnelle. Chaque tâche inclut : une commande, ce à quoi vous vous attendez, ce que signifie la sortie, et quelle décision prendre ensuite.

Task 1 — Windows : lister les profils Wi‑Fi enregistrés

cr0x@server:~$ netsh wlan show profiles
Profiles on interface Wi-Fi:

Group policy profiles (read only)
---------------------------------
    <None>

User profiles
-------------
    All User Profile     : Corp-WiFi
    All User Profile     : Guest-WiFi
    All User Profile     : AirportFreeWiFi

Signification : Cet appareil a trois profils stockés. Deux d’entre eux (« Guest-WiFi » et « AirportFreeWiFi ») ne valent probablement pas la peine d’être migrés.

Décision : N’exportez que le profil dont vous avez réellement besoin. Réduisez le périmètre.

Task 2 — Windows : exporter un seul profil sans clé en clair

cr0x@server:~$ mkdir C:\Temp\wifi-export
The directory was created successfully.

cr0x@server:~$ netsh wlan export profile name="Corp-WiFi" folder="C:\Temp\wifi-export"
Interface profile "Corp-WiFi" is saved in file "C:\Temp\wifi-export\Wi-Fi-Corp-WiFi.xml" successfully.

Signification : Vous avez exporté le profil, mais sans key=clear, il ne contiendra pas la PSK en clair.

Décision : Si votre but est de reproduire les paramètres (SSID/sécurité) sans divulguer la clé, c’est le comportement par défaut plus sûr. Si vous avez réellement besoin de la PSK, récupérez‑la explicitement et traitez‑la comme un secret.

Task 3 — Windows : afficher le mot de passe Wi‑Fi pour un profil spécifique

cr0x@server:~$ netsh wlan show profile name="Corp-WiFi" key=clear

Profile Corp-WiFi on interface Wi-Fi:
=======================================================================

Security settings
-----------------
    Authentication         : WPA2-Personal
    Cipher                 : CCMP
    Security key           : Present
    Key Content            : correct-horse-battery-staple

Signification : La PSK est affichée. C’est déjà sensible à l’écran.

Décision : Ne la capturez pas en screenshot. Ne la collez pas dans un commentaire de ticket. Placez‑la dans un canal secret approuvé ou saisissez‑la directement sur le dispositif de destination. Si la politique le permet, planifiez une rotation de la PSK après la migration.

Task 4 — Windows : exporter avec clé en clair (seulement si justifié)

cr0x@server:~$ netsh wlan export profile name="Corp-WiFi" folder="C:\Temp\wifi-export" key=clear
Interface profile "Corp-WiFi" is saved in file "C:\Temp\wifi-export\Wi-Fi-Corp-WiFi.xml" successfully.

Signification : Le XML contient désormais la PSK en clair.

Décision : Verrouillez immédiatement les permissions du fichier, planifiez un transfert sécurisé et une suppression rapide. Si vous pouvez éviter cette voie, faites‑le.

Task 5 — Windows : vérifier que le fichier exporté existe et n’est pas lisible par tous (vérification basique)

cr0x@server:~$ dir C:\Temp\wifi-export

 Directory of C:\Temp\wifi-export

02/05/2026  10:14 AM            3,912 Wi-Fi-Corp-WiFi.xml
               1 File(s)          3,912 bytes
               0 Dir(s)  120,000,000,000 bytes free

Signification : Le fichier est présent.

Décision : Vérifiez les ACL (tâche suivante). L’existence n’est pas la sécurité.

Task 6 — Windows : inspecter les ACL du répertoire d’export

cr0x@server:~$ icacls C:\Temp\wifi-export
C:\Temp\wifi-export BUILTIN\Administrators:(OI)(CI)(F)
                  NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                  CORP\alice:(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

Signification : Seuls les admins, SYSTEM et l’utilisateur peuvent y accéder. C’est acceptable pour un artefact de courte durée.

Décision : Si vous voyez des groupes larges (ex. « Users » ou « Everyone »), corrigez les permissions ou changez d’emplacement avant le transfert.

Task 7 — Windows : importer un profil sur la machine de destination

cr0x@server:~$ netsh wlan add profile filename="C:\Temp\wifi-export\Wi-Fi-Corp-WiFi.xml" user=all
Profile Corp-WiFi is added on interface Wi-Fi.

Signification : Le profil est installé. La connexion dépendra de la possession de la clé correcte et de paramètres de sécurité compatibles.

Décision : Tentez la connexion ; si elle échoue, vérifiez un désaccord de sécurité (transition WPA2 vs WPA3) ou des exigences 802.1X.

Task 8 — macOS : lister les réseaux Wi‑Fi préférés

cr0x@server:~$ networksetup -listpreferredwirelessnetworks en0
Preferred networks on en0:
    Corp-WiFi
    Guest-WiFi
    Hotel_Conference

Signification : Ces SSID sont connus du Mac.

Décision : Déterminez lesquels valent la peine d’être migrés. En milieu corporate, « Hotel_Conference » ne devrait pas figurer sur un appareil qui transporte des données sensibles.

Task 9 — macOS : récupérer un mot de passe Wi‑Fi depuis Keychain (interactif)

cr0x@server:~$ security find-generic-password -wa "Corp-WiFi"
correct-horse-battery-staple

Signification : Keychain a renvoyé le mot de passe (après invite, selon la politique).

Décision : Saisissez‑le directement sur le nouvel appareil ou transmettez‑le via une méthode secrète approuvée. Si vous avez un MDM, arrêtez cette pratique et déployez un profil de configuration.

Task 10 — Linux (NetworkManager) : lister les connexions enregistrées

cr0x@server:~$ nmcli -t -f NAME,TYPE,UUID connection show
Corp-WiFi:802-11-wireless:2a5c7c9b-6d3f-4b6a-9b9a-8c7a1d3f2a11
Wired connection 1:802-3-ethernet:aa2a7d11-1c8b-4c0b-9f0f-2d8c0d2e1f01
Guest-WiFi:802-11-wireless:bb6b2e9d-7aa1-4d0d-9a73-9f7a2a1f6d99

Signification : Vous avez deux profils Wi‑Fi stockés dans NetworkManager.

Décision : N’exportez que ce qui est nécessaire. Si « Guest-WiFi » est un profil de portail captif, ne le migrez pas.

Task 11 — Linux (NetworkManager) : inspecter si les secrets sont stockés et comment

cr0x@server:~$ nmcli -s connection show "Corp-WiFi" | sed -n '1,35p'
connection.id:                          Corp-WiFi
connection.type:                        802-11-wireless
802-11-wireless.ssid:                   Corp-WiFi
802-11-wireless.mode:                   infrastructure
802-11-wireless-security.key-mgmt:      wpa-psk
802-11-wireless-security.psk:           <hidden>
ipv4.method:                            auto
ipv6.method:                            auto

Signification : NM masque la PSK dans la sortie standard, mais elle peut rester stockée sur disque ou dans un keyring.

Décision : Choisissez d’exporter en copiant le fichier system‑connection (plus risqué) ou en ressaisissant la PSK sur la destination (plus sûr).

Task 12 — Linux : localiser le fichier de connexion NetworkManager et vérifier les permissions

cr0x@server:~$ sudo ls -l /etc/NetworkManager/system-connections/
total 8
-rw------- 1 root root  312 Feb  5 09:50 Corp-WiFi.nmconnection
-rw------- 1 root root  295 Feb  5 09:51 Guest-WiFi.nmconnection

Signification : Les fichiers sont root:root et lisibles seulement par root. C’est ce qu’on souhaite.

Décision : Si vous voyez -rw-r--r-- ou une propriété utilisateur différente ici, corrigez‑le avant toute autre action. Votre système fuit déjà des secrets localement.

Task 13 — Linux : exporter une connexion NM unique en sécurité (copie contrôlée)

cr0x@server:~$ sudo install -m 600 /etc/NetworkManager/system-connections/Corp-WiFi.nmconnection /tmp/Corp-WiFi.nmconnection

cr0x@server:~$ ls -l /tmp/Corp-WiFi.nmconnection
-rw------- 1 root root 312 Feb  5 10:01 /tmp/Corp-WiFi.nmconnection

Signification : Vous avez fait une copie lisible seulement par root dans un emplacement temporaire.

Décision : Transférez‑la via un canal sécurisé et supprimez‑la rapidement. Si vous ne pouvez pas garantir une manipulation sécurisée, n’exportez pas le fichier — reconfigurez manuellement.

Task 14 — Linux : importer la connexion sur une nouvelle machine et l’activer

cr0x@server:~$ sudo nmcli connection import type nm file /tmp/Corp-WiFi.nmconnection
Connection 'Corp-WiFi' (2a5c7c9b-6d3f-4b6a-9b9a-8c7a1d3f2a11) successfully imported.

cr0x@server:~$ nmcli connection up "Corp-WiFi"
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/12)

Signification : L’import a réussi et la connexion s’est activée.

Décision : Validez la connectivité et la résolution DNS ; puis supprimez l’artefact importé de /tmp.

Task 15 — Linux : vérifier les configs wpa_supplicant pour des PSK en clair (audit)

cr0x@server:~$ sudo grep -R "psk=" -n /etc/wpa_supplicant /etc 2>/dev/null | head
/etc/wpa_supplicant/wpa_supplicant.conf:12:    psk="correct-horse-battery-staple"

Signification : Il y a une PSK en clair dans un fichier de config.

Décision : Corrigez les permissions immédiatement et envisagez de migrer vers le stockage de clés de NetworkManager ou de supprimer la PSK si elle est obsolète. Si ce fichier fait partie des sauvegardes, vous sauvegardez des secrets.

Task 16 — Cross‑platform : vérifiez que vous êtes connecté au SSID prévu (éviter les evil twins)

cr0x@server:~$ nmcli -t -f ACTIVE,SSID,SIGNAL,SECURITY dev wifi | head -n 5
yes:Corp-WiFi:72:WPA2
no:Corp-WiFi-Guest:54:WPA2
no:Corp_WiFi:41:WPA2
no:FreeAirportWiFi:33:--
no:Corp-WiFi:29:WPA2

Signification : Plusieurs SSID similaires existent. L’un est actif, mais il y a des sosies.

Décision : Confirmez le BSSID (MAC de l’AP) si vous êtes dans un environnement hostile, et désactivez l’auto‑connexion pour les doublons suspects. N’importez pas et ne vous connectez pas automatiquement partout sans précaution.

Playbook de diagnostic rapide

Quand une « migration/export/import Wi‑Fi » échoue, les gens paniquent et commencent à cliquer au hasard. Ne faites pas ça. Diagnostiquez comme si vous étiez d’astreinte et souhaitiez dormir ensuite.

D’abord : confirmez le type de Wi‑Fi avec lequel vous avez affaire

• WPA‑Personal (PSK) : le mot de passe est le secret principal ; l’export/import peut fonctionner.
• WPA‑Enterprise (802.1X) : identifiants/certs importent ; l’export manuel est souvent le mauvais outil.
• Réseau invité avec portail captif : l’export est généralement inutile ; vous vous réauthentifierez via un navigateur de toute façon.

Ensuite : vérifiez que le profil exporté est bien celui attendu

• Vérifiez l’orthographe du SSID et l’indicateur de réseau masqué.
• Vérifiez le type de sécurité (transition WPA2 vs WPA3 peut casser les imports).
• Vérifiez si « se connecter automatiquement » doit être activé ou désactivé.

Troisième étape : validez les contraintes de politique du système de destination

• Windows : une GPO/MDM écrase‑t‑elle les profils WLAN ?
• macOS : l’utilisateur a‑t‑il la permission de révéler les mots de passe depuis Keychain ?
• Linux : les fichiers de connexion sont‑ils lisibles par NetworkManager (permissions/propriété) ?

Quatrième étape : assurez‑vous qu’il ne s’agit pas d’un problème radio/réseau qui fait croire à un problème de profil

• Vérifiez la qualité du signal, le band steering et si le SSID est réellement à portée.
• Vérifiez la synchronisation de l’heure (802.1X et validation des certificats peuvent échouer si l’heure est fausse).
• Vérifiez le DNS après association ; « connecté » n’est pas synonyme de « opérationnel ».

Erreurs courantes (symptômes → cause → correction)

Erreur 1 : « Import réussi » mais ça ne se connecte pas

Symptômes : Le profil s’importe correctement ; les tentatives de connexion bouclent ; l’utilisateur voit « Impossible de se connecter à ce réseau ».

Cause : Désaccord de sécurité (WPA2 vs WPA3), PSK incorrect, ou réseau entreprise requérant des paramètres EAP/certificats.

Correction : Revérifiez le type d’authentification dans le profil exporté. Pour WPA‑Personal, ressaisissez la PSK. Pour 802.1X, arrêtez les exports et déployez le profil entreprise approprié (MDM/GPO) incluant la chaîne de certificats.

Erreur 2 : le fichier d’export fuit dans la sync cloud

Symptômes : L’export a été placé dans Documents/Desktop ; plus tard on le retrouve sur plusieurs appareils ; alertes DLP ; réunion gênante.

Cause : Les dossiers utilisateurs étaient synchronisés ; l’export contenait la clé en clair (ou permettait de la récupérer).

Correction : Exportez uniquement vers un chemin local contrôlé, restreignez les permissions, transférez via une méthode approuvée et supprimez immédiatement. Faites une rotation de la PSK si elle a été exposée.

Erreur 3 : l’export/import massif migre des réseaux indésirables

Symptômes : Le nouvel appareil se connecte automatiquement à des réseaux « Guest » aléatoires ; l’utilisateur se plaint de confidentialité ; connexion instable en déplacement.

Cause : Vous avez exporté tous les profils enregistrés, y compris des hotspots publics et portails captifs.

Correction : N’exportez que les SSID ciblés. Purgez les réseaux anciens sur la source avant migration. Désactivez l’auto‑connexion pour tout ce qui n’est pas corporatif.

Erreur 4 : le profil Linux copié est ignoré par NetworkManager

Symptômes : Vous placez un fichier .nmconnection ; il n’apparaît pas dans nmcli connection show.

Cause : Permissions/propriété incorrectes ; NetworkManager refuse de lire des fichiers de connexion non sécurisés.

Correction : Assurez‑vous de la propriété root:root et des permissions 600 ; puis rechargez NetworkManager ou réimportez via nmcli.

Erreur 5 : 802.1X casse après un export « réussi »

Symptômes : L’appareil voit le SSID, tente de s’authentifier, échoue silencieusement ou reprompt sans cesse.

Cause : Certificat/clé privée manquante, CA de confiance manquante ou mauvaise méthode EAP sur la destination.

Correction : Considérez le Wi‑Fi d’entreprise comme de la gestion de configuration, pas des exports artisanaux. Utilisez MDM/GPO pour déployer le profil et les certificats. Validez la synchronisation de l’heure.

Erreur 6 : vous avez « sécurisé » le fichier en le zippant

Symptômes : Le fichier d’export a été compressé et envoyé par e‑mail. Quelqu’un dit : « C’est bon, c’est compressé. »

Cause : La compression n’est pas du chiffrement, et l’e‑mail n’est pas un coffre à secrets.

Correction : Utilisez une méthode de transfert chiffrée approuvée, ou évitez d’exporter des secrets. Si vous devez archiver, chiffrez avec un outil moderne et gérez la clé de chiffrement séparément.

Listes de contrôle / plan pas‑à‑pas

Checklist A — Migration ponctuelle (WPA‑Personal PSK)

1. Identifiez le SSID cible. Ne supposez pas que « Corp‑WiFi » soit le seul SSID corporatif.
2. Confirmez le mode de sécurité (WPA2/WPA3 ; personnel vs entreprise).
3. Décidez si vous devez vraiment exporter une clé. Si l’utilisateur peut taper la PSK et que la politique l’autorise, c’est souvent plus sûr que d’exporter.
4. Si vous devez exporter en clair, créez un répertoire dédié avec des permissions restreintes.
5. Exportez uniquement le profil unique. Ne faites pas d’export massif.
6. Transférez via une méthode sécurisée approuvée (ou média hors ligne contrôlé). Gardez la garde claire.
7. Importez sur la destination et vérifiez association + IP + DNS.
8. Supprimez immédiatement l’artefact d’export et videz la corbeille/Recycle où applicable.
9. Envisagez une rotation de la PSK si l’export a quitté un environnement contrôlé.

Checklist B — Wi‑Fi d’entreprise (802.1X)

1. Stoppez et demandez : existe‑t‑il déjà un profil MDM/GPO ? Utilisez‑le.
2. Déterminez la méthode EAP (EAP‑TLS, PEAP, TTLS) et les identifiants requis.
3. Inventoriez les certificats nécessaires : certificats client, clés privées et chaîne CA.
4. Déployez via l’outil de gestion avec moindre privilège et support de rotation.
5. Validez la synchronisation de l’heure et la confiance des certificats sur les endpoints.
6. Auditez le comportement d’auto‑connexion et interdisez les SSID non sécurisés quand possible.

Checklist C — Hygiène après migration

1. Supprimez les réseaux enregistrés non nécessaires sur le nouvel appareil.
2. Désactivez l’auto‑connexion sur les SSID invités/hôtels/aéroports.
3. Documentez la façon dont la clé a été manipulée et où elle a été stockée (idéalement : nulle part).
4. Pour les PSK partagés, prévoyez une rotation si une exposition est plausible.

Trois mini‑histoires d’entreprise

Mini‑histoire 1 — L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne avait un réseau Wi‑Fi corporate « que tout le monde connaissait » comme n’étant qu’un mot de passe. Un ingénieur support devait migrer la connectivité pour un lot de nouveaux portables avant un déménagement de site. Il fit l’évidence : exporter le profil Wi‑Fi depuis une machine Windows existante avec key=clear et partager le XML avec l’équipe desktop.

La mauvaise hypothèse : ils croyaient que le profil était « juste du Wi‑Fi ». En réalité, le nom du SSID était réutilisé dans plusieurs bâtiments, et un site était passé en mode transition WPA3 tandis qu’un autre restait en WPA2 uniquement à cause d’anciens scanners. Le profil importé poussa une partie des portables à tenter WPA3 en priorité, échouer, puis ne jamais retomber proprement en arrière. Les utilisateurs eurent une expérience de « connecté/pas d’internet » en boucle qui ressemblait à un problème DHCP.

Le dépannage dérailla parce que tout le monde s’était focalisé sur le mot de passe. Le mot de passe était correct. La négociation de sécurité ne l’était pas. Lorsqu’on compara enfin les capacités réellement annoncées du réseau avec les paramètres du profil, le déploiement des portables avait déjà commencé.

La correction fut ennuyeuse : arrêter les exports ; déployer deux profils distincts avec un nommage clair par site ; appliquer via les outils de gestion ; valider avec un appareil test à chaque emplacement. Ils firent aussi une rotation de la PSK parce que le XML avait été envoyé par e‑mail en interne, et l’e‑mail a la rétention d’une formation géologique.

Mini‑histoire 2 — L’optimisation qui s’est retournée contre eux

Une société de services globale essaya d’accélérer les renouvellements de portables en créant un script de migration « en une commande ». Il récoltait tous les profils WLAN enregistrés sous Windows via netsh export, les empaquetait et les copiait dans le répertoire de l’utilisateur sur le nouveau portable. Le script faisait gagner du temps. Il a aussi importé une décennie d’historique de voyage.

Le retour de bâton se manifesta sous la forme d’un rapport d’incident : plusieurs portables se connectaient automatiquement à des réseaux ouverts nommés « Hotel_Conference » et « Guest ». Pas parce que les utilisateurs les avaient choisis, mais parce que les profils importés disaient à l’OS que ces réseaux étaient « connus ». Les attaquants adorent les réseaux connus. Les AP evil twin sont bon marché et dangereux.

L’équipe avait optimisé pour la vitesse et oublié que l’état de connectivité fait partie de votre surface d’attaque. Les machines n’étaient pas « compromises » de façon spectaculaire, mais les identifiants et le trafic de navigation furent exposés aux réseaux hostiles des aéroports et hôtels. La société dut durcir la politique endpoint Wi‑Fi et procéder à un nettoyage de flotte.

La nouvelle approche fut plus lente mais plus sûre : migrer uniquement les SSID corporatifs via des profils gérés ; ne pas migrer les SSID publics ; désactiver explicitement l’auto‑connexion pour tout ce qui n’est pas propriétaire. Le processus de renouvellement prit quelques minutes de plus par appareil. C’était toujours moins cher que de courir après des risques à l’échelle de la flotte.

Mini‑histoire 3 — La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation de santé gérait un mix de portables Windows et d’appareils cliniques sous Linux. Leur Wi‑Fi était 802.1X d’entreprise avec certificats pour des appareils incapables de gérer des flux MFA modernes. Ils avaient un processus de provisioning strict que tout le monde qualifiait de « bureaucratique à mort ».

Lors d’une extension de bâtiment, un sous‑traitant demanda l’accès Wi‑Fi et proposa « d’exporter simplement le profil depuis un des appareils ». La demande semblait raisonnable — jusqu’à ce qu’on réalise qu’un export inclurait probablement la clé privée, qui est en fait une identité d’appareil. Si cette clé fuit, on ne tourne pas simplement un mot de passe ; on révoque et réémet des certificats, éventuellement à grande échelle.

La pratique ennuyeuse de l’organisation était : pas d’export manuel des secrets Wi‑Fi d’entreprise. Le provisioning passait par un enrolment géré. Les certificats étaient délivrés par appareil, avec traçabilité et procédures de révocation. Le sous‑traitant obtint l’accès via un réseau invité segmenté, pas en clonant l’identité d’un appareil clinique.

Deux mois plus tard, un portable fut volé dans une voiture. Ce fut moche, mais pas catastrophique. Comme l’accès de l’appareil était basé sur des certificats et géré centralement, ils révoquèrent le certificat et invalidèrent l’identité rapidement. Si cette clé privée avait été disséminée via des « exports serviables », la révocation serait devenue un jeu d’hypothèses.

Blague n°2 : La manière la plus rapide de « sauvegarder le Wi‑Fi » est d’écrire le mot de passe sur un post‑it — aussi la voie la plus rapide pour obtenir une promotion au poste de « ancien employé ».

FAQ

1) Est‑il légal d’exporter des mots de passe Wi‑Fi enregistrés depuis un appareil ?

Cela dépend de l’autorisation et de la politique. Sur des actifs corporatifs, considérez cela comme un accès privilégié. Si vous n’êtes pas explicitement autorisé, ne le faites pas. Si vous l’êtes, journalisez‑le comme toute autre opération de gestion de secrets.

2) Dois‑je exporter tous les profils Wi‑Fi pour faciliter la migration ?

Non. N’exportez que ce dont vous avez besoin. L’export massif inclut des hotspots publics et des réseaux anciens qui augmentent le risque d’auto‑connexion et l’encombrement. La commodité maintenant devient un incident plus tard.

3) Est‑ce que exporter avec key=clear est toujours mauvais ?

Pas toujours, mais cela doit rester un dernier recours. Si vous devez l’utiliser, contraignez la portée (SSIDs uniques), limitez l’accès (ACLs), réduisez le temps de vie (suppression rapide) et envisagez une rotation de la PSK ensuite.

4) Pourquoi macOS rend‑il plus difficile de vider les mots de passe Wi‑Fi ?

Parce que vider des secrets dans des fichiers est un mode d’échec courant. La récupération Keychain est volontairement interactive et soumise à autorisation. Pour les flottes, Apple attend des profils de configuration via MDM, pas des exports artisanaux de mots de passe.

5) Pour le Wi‑Fi d’entreprise (802.1X), puis‑je « exporter le mot de passe » de la même manière ?

Souvent il n’y a pas un seul mot de passe partagé. Vous pouvez avoir des identifiants utilisateur, des identifiants appareil ou des certificats. L’export peut exposer des clés privées. Utilisez le déploiement géré et le cycle de vie des certificats.

6) Si je fais une rotation de la PSK après la migration, suis‑je en sécurité ?

Plus sûr, oui. Pas magiquement à l’abri. Vous devez toujours vous assurer que l’artefact d’export est supprimé et n’est pas synchronisé/sauvegardé. La rotation est une remédiation, pas une permission d’être négligent.

7) Puis‑je stocker des profils Wi‑Fi exportés dans un gestionnaire de mots de passe ?

Stocker la PSK dans un gestionnaire de secrets approuvé peut être raisonnable. Stocker des fichiers d’export complets est généralement inutile et risqué, car ils peuvent contenir plus de métadonnées que prévu. Préférez stocker le secret minimal (la PSK) et recréer le profil à la demande.

8) Pourquoi mon Wi‑Fi migre sur Linux mais le DNS ne fonctionne pas ?

L’association Wi‑Fi peut réussir tandis que les paramètres DNS diffèrent. Un profil peut inclure des surcharges DNS, des dépendances VPN ou des paramètres proxy. Validez l’IP, la route par défaut et la configuration du résolveur après l’import.

9) Quelle est la façon la plus sûre de transférer le Wi‑Fi vers un nouveau portable corporate ?

Utilisez votre plateforme de gestion des endpoints pour déployer le profil Wi‑Fi (et les certificats si nécessaire). Les exports manuels doivent rester pour le break‑glass seulement, avec approbation explicite et nettoyage.

10) Le fait de masquer le SSID change‑t‑il la façon de gérer les exports ?

Les SSID masqués poussent souvent les appareils à émettre plus de probes, ce qui peut divulguer le nom du SSID et aggraver la confidentialité. Si vous devez supporter des SSID masqués, soyez encore plus strict sur les appareils qui reçoivent le profil et désactivez l’auto‑connexion quand ce n’est pas nécessaire.

Conclusion : prochaines étapes pratiques

Exporter des profils Wi‑Fi avec mots de passe n’est pas un tour de passe‑passe ingénieux. C’est de la gestion de secrets avec une interface fine. Traitez‑le comme tel et le processus restera rapide, ennuyeux et sûr — la meilleure combinaison possible en production.

1. Décidez ce que vous migrez : réseau PSK, 802.1X d’entreprise ou invité/portail captif.
2. N’exportez que ce que vous devez, idéalement un seul SSID.
3. Privilégiez le déploiement géré pour le Wi‑Fi corporate. Les exports manuels ne montent pas en charge et ne s’audient pas bien.
4. Si vous manipulez des clés en clair, restreignez l’accès, raccourcissez la durée de vie, transférez de manière sécurisée et supprimez rapidement.
5. Après la migration, élaguez les réseaux inutiles et désactivez l’auto‑connexion là où elle n’a pas sa place.
6. En cas de doute, faites une rotation de la PSK et documentez ce qui s’est passé. Les secrets détestent l’ambiguïté.