Mot de passe d'hébergement différent de celui du CMS

Pourquoi le même secret rouvre la porte

Vous changez le mot de passe WordPress. Le panel o2switch, lui, est encore `Marque2020!`. L'attaquant y crée un nouvel utilisateur FTP, réécrit `wp-config`, pose un mu-plugin. L'admin « propre » n'était qu'un théâtre. C'est le scénario le plus banal des dossiers « on a tout changé ».

L'inverse existe : panel neuf, admin CMS ancien, session encore ouverte. Un cookie, un mot de passe d'application, et le fichier que vous venez de retirer réapparaît. Distinguer les tiroirs n'est pas de la paranoïa. C'est de l'arithmétique.

Si le même secret sert aussi la messagerie, partez du principe que tout a été lu : devis, tickets hébergeur, reset de comptes. Tournez la messagerie pour elle-même, pas « avec le site ». Voir quels mots de passe changer.

Trois tiroirs, trois mots de passe

Panel d'hébergement : il commande FTP, cron, parfois la base et les certificats. SFTP ou FTP : un utilisateur dédié, pas le compte « principal » recyclé. Administration du CMS : un compte nominatif, le vôtre, plus ceux que vous assumez. Trois chaînes. Aucune n'est un alias de l'autre.

Ensuite seulement : mot de passe de la base (et le fichier qui le contient), SMTP du site, Search Console (plutôt des invitations que le compte Google personnel). Chaque couche que l'attaquant a pu voir se tourne. Chaque couche qu'il n'a pas vue se distingue quand même, pour la prochaine fois.

Sur un VPS, ajoutez la clé SSH — idéalement une clé, pas un mot de passe root réutilisé. Le « mot de passe unique du serveur » est le cousin du post-it.

• Panel ≠ SFTP ≠ wp-admin / back-office.
• Base et `.env` / `wp-config` : secrets propres.
• SMTP, Stripe, Brevo : clés distinctes, révocables.

L'ordre de rotation, pas la liste

Panel d'abord, puis SFTP, puis CMS, puis base, puis services annexes. Inverser laisse une session panel ouverte : quelqu'un recrée ce que vous venez de fermer. C'est le même ordre que dans les premiers gestes.

Ne « testez pas » l'ancien mot de passe sur les trois interfaces pour « voir s'il marchait vraiment ». Vous venez de le confirmer à quiconque écoute, et vous vous persuadez qu'il est encore utile. Il ne l'est plus. Générez, stockez, passez au suivant.

Si le FTP est déjà coupé par l'hébergeur, passez par le manager : réinitialisation, puis rotation complète dès que l'accès revient. Ne remettez pas l'ancien secret « le temps que ça se calme ».

Ce que « unique » veut dire vraiment

`Marque2024!` et `Marque2025!` ne sont pas deux secrets. Une phrase longue, générée, jamais réemployée, y compris pour le « petit site vitrine » à côté de la boutique. C'est ce petit site qui sert souvent de rampe.

Unique veut aussi dire : pas le mot de passe Wi-Fi, pas le code de la box, pas le PIN de la carte. Le gestionnaire existe pour ça. La mémoire, non.

Les questions secrètes du registrar (`nom du chien`) sont des secrets aussi. Un attaquant qui a lu la messagerie les reset. Activez la 2FA chez le registrar et chez l'hébergeur. Ce n'est pas du luxe post-incident : c'est la clôture.

Gestionnaire, pas la boîte partagée de l'agence

Un fichier `mots-de-passe.xlsx` sur le Drive, un canal Slack `#it`, un email « pour l'équipe » : ce n'est pas un coffre. C'est une copie de plus à considérer comme lue si un compte Google ou une boîte a fuité.

Un gestionnaire permet le partage temporaire, la révocation, l'historique. C'est le même outil que pour donner l'accès à un nettoyeur — et pour le lui retirer. Si l'agence insiste pour un Google Doc, c'est un critère de choix, pas un détail.

Vous n'avez pas à nous donner le coffre. Vous donnez trois accès révocables. Le reste reste chez vous. Créer un compte n'exige aucun secret a priori.

Sessions, clés, mots de passe d'application

Changer le mot de passe CMS sans invalider les sessions laisse les cookies vivants. WordPress : régénérer les clés AUTH dans `wp-config` si le fichier a pu être lu. PrestaShop : déconnecter les employés. Magento : révoquer les intégrations.

Les mots de passe d'application et les jetons REST survivent au mot de passe principal. Relisez-les un par un. C'est souvent là que « j'ai tout changé » ment.

Search Console, GTM, Business Manager : ce ne sont pas des mots de passe du CMS. Ce sont des invitations. Révoquez les inconnues. Un container GTM n'a pas besoin de votre mot de passe panel pour servir un skimmer. GTM détourné.

Le voisin de compte et le registrar

Deux sites, un panel, un seul mot de passe : nettoyer le premier et laisser le second avec l'ancien secret, c'est offrir une passerelle. Isolez les utilisateurs FTP par dossier si l'hébergeur le permet. Sinon, assumez que le compte entier est le périmètre.

Le registrar (où se achète le `.fr`) n'est pas l'hébergeur. Un secret distinct, une 2FA, un contact mail qui n'est pas `admin@le-site-pirate`. Un transfert de domaine « pour se rassurer » pendant l'incident est un autre projet, souvent une mauvaise idée à J+1.

Si l'ancien développeur a encore le panel, le problème n'est plus seulement la réutilisation : c'est la révocation. Ancien développeur.

Vérifier que l'ancien ne marche plus

Après rotation : ouvrez une navigation privée, tentez l'ancien secret sur panel, SFTP, admin — uniquement pour confirmer le refus. Puis oubliez-le. Vérifiez qu'aucun utilisateur FTP fantôme n'a été ajouté « entre-temps ».

Regardez les sessions actives et les derniers logins. Un succès à 4 h du matin avec l'ancien mot de passe, après votre rotation de 18 h, veut dire que la rotation n'a pas pris partout (cache, réplication, second panel).

Surveillez trente jours : nouvel admin, nouveau PHP. La surveillance attrape ce que la rotation a manqué. Les deux gestes se tiennent.