Faut-il vraiment changer tous les mots de passe après une faille de sécurité ?

Pourquoi Google insiste-t-il sur cette rotation des mots de passe ?

Une vulnérabilité exploitée ouvre souvent plus de portes qu'on ne le pense. Les attaquants ne se contentent pas de corriger le bug à votre place : ils collectent les credentials en clair stockés dans les bases, les fichiers de configuration ou les logs.

Même si tu as colmaté la brèche, les mots de passe déjà exposés restent valides. Un attaquant patient peut attendre des semaines avant de les réutiliser. La rotation immédiate invalide ces clés volées et coupe l'accès résiduel.

Quels comptes sont concernés par cette rotation ?

Google parle de tous les comptes d'accès au site, ce qui englobe bien plus que ton admin WordPress. FTP, SSH, bases de données MySQL, panneaux d'hébergement, CDN, APIs tierces : chaque credential compromis donne une porte d'entrée alternative.

La plupart des praticiens oublient les comptes de service et les clés API. Un attaquant malin cible justement ces accès secondaires, moins surveillés que le compte super-admin. Pense aussi aux anciens prestataires qui ont encore des accès actifs.

Cette mesure suffit-elle à sécuriser le site après une attaque ?

Changer les mots de passe n'est qu'une première étape défensive, pas une solution complète. Si l'attaquant a installé une backdoor dans le code, modifié des fichiers core ou créé des comptes cachés, la rotation des credentials ne suffit pas.

Il faut combiner cette action avec un audit des fichiers modifiés, une vérification des utilisateurs créés récemment et un scan malware. Les attaques sophistiquées laissent plusieurs points d'entrée : fermer une seule porte ne sécurise pas la maison.

• Rotationner tous les credentials immédiatement après la correction de la vulnérabilité
• Inclure les comptes FTP, SSH, bases de données, APIs et services tiers dans la rotation
• Combiner avec un audit complet des fichiers, utilisateurs et logs d'accès
• Documenter qui avait accès avant l'incident pour détecter les accès résiduels
• Surveiller les tentatives de connexion échouées pendant 30 jours minimum après l'incident

Cette recommandation est-elle cohérente avec les pratiques observées sur le terrain ?

Oui, mais elle arrive souvent trop tard. Les sites attaqués découvrent la brèche des semaines après l'intrusion initiale, quand les credentials ont déjà servi à installer des backdoors multiples. Changer les mots de passe à ce stade limite les dégâts futurs mais ne répare pas le passé.

Ce que Google ne dit pas : la plupart des réinfections proviennent de credentials oubliés dans des fichiers de configuration versionnés sur GitHub ou dans des backups accessibles. La rotation doit s'accompagner d'un nettoyage des dépôts Git et d'une révocation des clés API exposées publiquement.

Quelles nuances faut-il apporter à cette consigne ?

La rotation des mots de passe devient contre-productive si elle pousse les équipes à choisir des credentials faibles parce qu'ils devront les retenir. Privilégie un gestionnaire de mots de passe et génère des passphrases aléatoires de 20+ caractères.

Autre point : les certificats SSL/TLS et clés privées ne sont pas mentionnés par Google mais méritent attention. Si la vulnérabilité donnait accès au système de fichiers, ces clés ont pu être exfiltrées. Leur rotation implique de regénérer les CSR et de réémettre les certificats. [A verifier] : Google reste vague sur le périmètre exact des "comptes d'accès" concernés.

Dans quels cas cette règle ne s'applique-t-elle pas strictement ?

Si tu utilises une authentification à deux facteurs matérielle (clés FIDO2) sur tous les accès critiques, le risque d'exploitation des credentials volés chute drastiquement. L'attaquant aurait besoin du dispositif physique en plus du mot de passe.

Deuxième exception : les environnements avec authentification SSO centralisée et rotation automatique des tokens. Dans ce cas, révoquer les sessions actives et forcer une réauthentification peut suffire si les tokens ont une durée de vie courte. Mais attention : ces architectures restent rares dans le monde WordPress et CMS classiques.

Que faut-il faire concrètement après avoir corrigé la faille ?

Commence par lister tous les points d'accès au site : admin CMS, FTP/SFTP, SSH, bases de données, panneaux hébergeur, accès CDN, comptes APIs (Google Search Console, Analytics, outils SEO tiers). Un tableur simple avec colonnes "Service / Login / Dernière modif" aide à ne rien oublier.

Change ensuite les credentials dans cet ordre de priorité : accès root et admin d'abord, puis bases de données, puis services annexes. Entre chaque rotation, vérifie que les services redémarrent correctement et que les scripts automatisés (cron, déploiements) fonctionnent avec les nouvelles clés.

Quelles erreurs éviter lors de la rotation des mots de passe ?

Ne pas documenter les nouveaux credentials dans un fichier texte sur le serveur compromis. Stocke-les dans un gestionnaire de mots de passe type 1Password, Bitwarden ou Dashlane, jamais dans un Google Doc partagé ou un fichier .txt local.

Autre erreur fréquente : oublier de révoquer les anciennes clés API. Changer le mot de passe Google Search Console ne suffit pas si l'ancien token OAuth reste actif dans une app tierce compromise. Révoque tous les accès OAuth et regénère les tokens.

Comment vérifier que le site reste sécurisé après l'incident ?

Mets en place un monitoring actif des connexions pendant 30 jours minimum. Les plugins type Wordfence ou Sucuri montrent les tentatives de login échouées et les IPs suspectes. Un pic de tentatives sur d'anciens logins confirme que les credentials volés circulent.

Parallèlement, scanne les fichiers modifiés récemment avec diff ou WP-CLI pour détecter des backdoors résiduelles. Un simple `wp core verify-checksums` révèle les fichiers WordPress altérés. Pour les thèmes et plugins custom, compare avec ta dernière version propre en Git.

• Inventorier tous les accès système, CMS, bases de données et APIs tierces
• Générer des mots de passe aléatoires de 20+ caractères via gestionnaire dédié
• Révoquer tous les tokens OAuth et clés API actifs, même ceux qui semblent sains
• Activer l'authentification à deux facteurs sur tous les comptes critiques
• Surveiller les logs de connexion et les tentatives échouées pendant 30 jours
• Scanner les fichiers modifiés et vérifier l'intégrité des core files