Module 7 · 7.3
Français
Connexion : mots de passe, authentification à deux facteurs et brute force
Module 7: Sécurité · Temps de lecture : 9 minutes
Objectif pédagogique : après cette leçon, vous saurez protéger la connexion à votre site avec des mots de passe forts, l'authentification à deux facteurs et la limitation des tentatives de connexion, et vous saurez ce qu'est xmlrpc.php.
Notions clés : gestionnaire de mots de passe, phrase secrète, mot de passe unique, authentification à deux facteurs (2FA, TOTP), passkey, brute force, limitation des tentatives de connexion, wp-login.php par adresse IP, xmlrpc.php, noms d'utilisateur divulgués (REST, ?author=), mots de passe d'application
Le mot de passe : long et unique
Un bon mot de passe a deux qualités :
- Long : la longueur compte plus que les caractères spéciaux. Une phrase secrète de quatre ou cinq mots aléatoires (
tamis-pingouin-octobre-lanterne) est plus solide et plus facile à retenir queM0td3pa$se!. Il est recommandé d'utiliser un mot de passe unique d'au moins 12 caractères, de préférence une phrase de passe. - Unique : à n'utiliser nulle part ailleurs. Le credential stuffing (leçon 7.1) ne fonctionne que si vous réutilisez un mot de passe.
Personne ne retient des dizaines de mots de passe longs et uniques. Utilisez donc un gestionnaire de mots de passe : un programme qui les crée, les conserve et les saisit pour vous. Vous n'avez alors qu'un seul mot de passe à retenir : celui du gestionnaire lui-même, que vous protégez également avec l'authentification à deux facteurs.
Pour savoir si un mot de passe figure dans une fuite de données connue, vous pouvez consulter haveibeenpwned.com. Si votre adresse e-mail apparaît dans une fuite, changez le mot de passe sur chaque service où vous avez utilisé ce même mot de passe.
Authentification à deux facteurs
Avec l'authentification à deux facteurs (2FA), vous avez besoin, en plus de votre mot de passe, d'un élément supplémentaire au moment de la connexion : généralement un code à six chiffres généré par une application sur votre téléphone (une application d'authentification, selon la norme TOTP). Un intrus en possession de votre mot de passe ne pourra alors pas entrer.
WordPress n'intègre pas nativement l'authentification à deux facteurs. Vous l'ajoutez avec une extension. Il en existe beaucoup ; une extension simple est Two Factor, créée par des contributeurs de WordPress lui-même. Les extensions de sécurité l'intègrent aussi souvent. Lors de votre choix, portez attention à :
- la prise en charge des applications TOTP et des codes de secours (en cas de perte de votre téléphone) ; les codes par e-mail sont plus faibles, car votre messagerie peut elle aussi être piratée ;
- la possibilité de la rendre obligatoire pour les administrateurs et rédacteurs ;
- les passkeys : connexion avec votre empreinte digitale, votre visage ou une clé de sécurité, sans mot de passe. Des extensions existent également pour cela. Les passkeys résistent au phishing, car elles ne fonctionnent que sur le site authentique.
Activez également l'authentification à deux facteurs sur tout ce qui entoure votre site : votre panneau d'hébergement, votre messagerie, votre registrar et votre gestionnaire de mots de passe. Un intrus qui prend le contrôle de votre panneau d'hébergement n'a pas besoin de votre mot de passe WordPress.
Brute force et limitation des tentatives de connexion
Un site WordPress ouvert reçoit toute la journée des tentatives de connexion sur wp-login.php, souvent avec le nom admin et des listes de mots de passe courants. Avec un mot de passe long et la 2FA, ces tentatives n'aboutissent pas, mais chacune d'elles sollicite votre serveur (un démarrage complet de WordPress). En cas de vague importante, votre site devient lent.
WordPress lui-même ne limite pas le nombre de tentatives. Ce qui aide, dans l'ordre du « blocage le plus en amont » :
- Au niveau du serveur : de nombreux hébergeurs bloquent une adresse IP qui effectue de nombreuses tentatives échouées en peu de temps, avant même que WordPress ne démarre (via un pare-feu ou une fonction du serveur web). Demandez à votre hébergeur ce qu'il en est.
- wp-login.php réservé à votre adresse IP : avec quelques lignes dans
.htaccess(pour LiteSpeed et Apache) :
<Files wp-login.php>
Require ip 192.0.2.10
</Files>Cela fonctionne bien si vous disposez d'une adresse IP fixe. Si ce n'est pas le cas (à domicile, sur votre téléphone), vous vous bloquez vous-même dès que votre adresse change. Une alternative consiste à ajouter un mot de passe supplémentaire sur la page de connexion (un « dossier protégé », authentification basique) différent de votre mot de passe WordPress.
- Une extension qui limite les tentatives : après cinq tentatives échouées, l'adresse IP est bloquée pendant un certain temps. Cela fonctionne, mais seulement une fois que WordPress a déjà démarré, donc la charge de calcul subsiste.
Masquer ou renommer la page de connexion (par exemple /ma-connexion au lieu de /wp-login.php) réduit le bruit dans votre journal. Ce n'est pas une véritable mesure de sécurité, et certaines extensions et certains thèmes s'attendent à l'adresse standard. C'est une bonne option en complément, jamais à la place d'un mot de passe fort et de la 2FA.
xmlrpc.php
xmlrpc.php est une ancienne interface datant d'avant l'API REST, qui permet à des applications et à d'autres sites de communiquer avec WordPress. Elle est encore utilisée par certaines applications, par Jetpack et par quelques intégrations. Pour la plupart des sites, elle est superflue.
Les intrus apprécient xmlrpc.php, car elle permet d'essayer des centaines de mots de passe en une seule requête (grâce à la fonction system.multicall), et parce qu'elle peut être détournée pour attaquer d'autres sites (pingbacks). Voici ce qu'il faut faire :
- Vous ne l'utilisez pas : bloquez-la. Certains hébergeurs, dont WebOké, bloquent xmlrpc.php par défaut au niveau du serveur. Sinon, utilisez une règle dans
.htaccessou une extension de sécurité. - Vous l'utilisez (par exemple pour une application qui en a besoin) : laissez-la ouverte, mais assurez-vous d'avoir des mots de passe forts, la 2FA et une limitation des tentatives. Les applications modernes utilisent généralement l'API REST avec un mot de passe d'application (leçon 3.3).
Noms d'utilisateur divulgués
Dans la leçon 3.3, vous avez vu que WordPress affiche une forme dérivée des noms d'utilisateur :
https://example.com/?author=1redirige vers/author/<nom>/;https://example.com/wp-json/wp/v2/usersaffiche une liste des identifiants (slugs) de toutes les personnes ayant publié du contenu.
Est-ce grave ? Un nom d'utilisateur n'est pas un mot de passe. Avec un mot de passe long et unique et la 2FA, cela importe peu. Mais cela donne à un intrus la moitié des informations de connexion et facilite le phishing ciblé. Mesures raisonnables :
- donnez aux administrateurs un nom d'utilisateur différent de leur nom public, et ne publiez pas de contenu avec un compte administrateur (leçon 3.3) ;
- limitez la liste des utilisateurs dans l'API REST avec une extension de sécurité ou quelques lignes de code, si vous n'en avez pas besoin. Ne fermez pas complètement l'API REST : l'éditeur de blocs et de nombreuses extensions en ont besoin.
Mots de passe d'application
Les mots de passe d'application (leçon 3.3) constituent un moyen sûr de donner accès à une application ou à un système, mais ils contournent votre authentification à deux facteurs : une application munie d'un mot de passe d'application n'a pas besoin de code. Ne les créez que lorsque c'est nécessaire, pour un compte avec un rôle limité, et révoquez-les lorsque vous n'utilisez plus l'intégration concernée.
Résumé
- Utilisez des mots de passe longs et uniques (phrases secrètes) dans un gestionnaire de mots de passe.
- Activez l'authentification à deux facteurs, avec une extension dans WordPress et aussi sur votre panneau d'hébergement, votre messagerie et votre registrar.
- Bloquez les tentatives de connexion le plus tôt possible : au niveau du serveur, avec une règle IP ou un mot de passe supplémentaire, ou avec une extension.
- Bloquez xmlrpc.php si vous ne l'utilisez pas.
- Des noms d'utilisateur divulgués ne sont pas une catastrophe, mais un signal : ne publiez pas en tant qu'administrateur et limitez la liste des utilisateurs de l'API REST si vous n'en avez pas besoin.
Quiz
Exercice
Exercice A7.3: Que révèle votre site lors de la connexion ? Indiquez l'adresse de votre site et prouvez qu'il s'agit bien du vôtre (avec le code de l'exercice, en tant qu'enregistrement TXT ou fichier). Le programme vérifie trois éléments : si xmlrpc.php renvoie une liste de fonctions (ouvert) ou est bloqué, si /wp-json/wp/v2/users affiche des noms d'utilisateur (slugs), et vers quoi redirige /?author=1. Indiquez si vous avez besoin de xmlrpc.php ; sinon, un xmlrpc.php ouvert apparaît en rouge. Des slugs divulgués apparaissent en orange, avec une explication.
Exercice D7.3: Activer l'authentification à deux facteurs. Activez l'authentification à deux facteurs pour tous les administrateurs de votre site WordPress, ainsi que sur votre panneau d'hébergement et votre messagerie. Conservez les codes de secours dans votre gestionnaire de mots de passe. Cochez, pour chaque élément, qu'il est activé, et notez quelle méthode vous utilisez (application, passkey, e-mail) et où se trouvent les codes de secours. Notez également comment vous protégez davantage wp-login.php et pourquoi vous avez choisi cette méthode.
Exercice D7.3: Activer l'authentification à deux facteurs
Cet exercice, vous le faites vous-même ; personne ne le vérifie. Cochez ce que vous avez fait et marquez l'exercice comme terminé.
Pour les administrateurs, préférez une application ou une passkey plutôt que l'e-mail seul. Vous pouvez autoriser une adresse IP fixe sur wp-login.php ; avec des adresses variables, la limitation des tentatives de connexion est plus adaptée.
Vos cases cochées et vos notes restent uniquement dans ce navigateur ; nous ne les envoyons nulle part. Si vous êtes connecté, nous enregistrons dans Mes formations uniquement le fait que vous avez terminé l'exercice.
Pour aller plus loin
Ces articles décrivent les étapes dans les panneaux de WebOké ; dans d'autres panneaux, le fonctionnement est similaire.
- Guide DirectAdmin 3.7: Mots de passe sécurisés et que faire en cas de mot de passe compromis
- Vérification en deux étapes dans Mon WebOké et configuration d'une application d'authentification
- WordPress : l'accès à xmlrpc.php ne fonctionne pas
- Sécuriser wp-login.php de WordPress
- Guide DirectAdmin 15.9: Répertoires protégés par mot de passe
- Se connecter en toute sécurité (ressource gouvernementale néerlandaise, en néerlandais) : https://veiliginternetten.nl/veilig-inloggen/
- Attaques par force brute (developer.wordpress.org, en anglais) : https://developer.wordpress.org/advanced-administration/security/brute-force/
