Forcer les mots de passe clients après une lecture de base
Si la table des comptes a été lue, même hashée, imposez une réinitialisation. Prévenez. Un hash faible se casse. Attendre « pour ne pas déranger » laisse une fenêtre où l'attaquant se connecte avec les mêmes secrets.
Si la table users a été lue, même hashée, imposez une réinitialisation. Prévenez. Un hash faible se casse. Attendre « pour ne pas déranger » laisse une fenêtre ouverte.
Quand le reset n'est pas optionnel
Lecture avérée ou fortement plausible de la table utilisateurs (CMS, boutique, espace client). Export trouvé. Injection avec SELECT plausible. Là, le confort « on verra après les soldes » n'a pas sa place. Le constat le note ; la remédiation le fait.
Un défacement sans touche à cette table : on ne force pas toute la base pour faire moderne. On ne s'en sert pas non plus comme excuse pour ne jamais regarder la table.
Les comptes jamais connectés depuis trois ans restent des comptes. L'attaquant n'a pas votre critère marketing.
Hash faible, hash correct, clair
Clair en base : incident double. Reset immédiat, et dette de stockage — mots de passe en clair. Notification presque toujours dans le paysage.
Hash ancien (schémas dépassés, sans sel correct) : partez du principe qu'il se casse hors ligne une fois le dump parti. Reset. Hash moderne : le reset reste justifié si le dump est sorti — le secret peut fuir autrement (réutilisation, malware poste) et les sessions vivent encore.
Vous n'avez pas à publier l'algorithme. Vous avez à agir comme si le dump existait dès que la lecture est dans le constat. Voir réutilisation chez vos clients.
- Clair : reset + correction du stockage.
- Hash faible + lecture : reset sans débat.
- Hash moderne + dump : reset quand même, sessions en plus.
Imposer, pas « inviter à »
Un email « pensez à changer votre mot de passe » laisse 80 % des comptes inchangés. Le CMS doit expirer le secret : connexion = flux de reset, jetons d'ancien mot de passe invalides. WooCommerce, Prestashop, WordPress : les mécanismes existent ; un plugin improvisé qui envoie un lien faible aggrave.
Prévenez avant ou pendant, pas trois jours après que les gens soient déjà lock-out sans explication. Le texte : informer.
Les comptes qui n'ont pas d'email valide : désactivez-les plutôt que de les laisser avec l'ancien secret.
Sessions et cookies dans le même geste
Un mot de passe neuf avec une session admin ou client encore valide, c'est une porte. Videz les sessions, régénérez les clés de sel CMS si le produit le prévoit, expirez les cookies boutique. Détail : cookies et sessions.
Les « rester connecté » des applications mobiles liées au même compte : révoquez les jetons si l'app le permet.
Sans ça, le reset est un théâtre pour l'écran de login web seulement.
Le message qui accompagne
Pourquoi (données de compte potentiellement lues). Quoi faire (choisir un secret unique, ici et ailleurs). Où cliquer (URL que les gens connaissent, tapée, pas seulement un lien). Vous ne demanderez jamais le nouveau mot de passe par email.
Si le domaine mail est encore instable, le bandeau site + l'espace client à la prochaine visite évitent un pic de phishing de marque qui imite votre reset.
Une phrase sur la réutilisation suffit. Pas un cours de cryptographie.
Comptes admin, prestataires, API
Les administrateurs se reset en premier, avec 2FA. Les comptes d'agence : nouveau secret, plus de partage par email. Les clés API et application passwords ne sont pas des « mots de passe clients » mais tombent dans la même rotation.
Un admin fantôme se supprime, on ne lui « change pas le mot de passe pour voir ».
Le panel d'hébergement n'est pas la table clients ; il se tourne quand même, souvent avant. Ordre rappelé dans les premiers gestes utiles : panel, puis CMS, puis clients.
Ce que le reset ne répare pas
Ni la porte dérobée, ni une injection encore ouverte, ni un forwarder mail. Faire le reset et s'arrêter, c'est offrir le nouveau secret à la même entrée.
Ni une fuite d'emails déjà partis en liste. Les personnes restent exposées au phishing ; le reset réduit l'accès à votre site, pas à leur boîte Gmail.
Ni le stockage en clair : si vous reset et réécrivez encore en clair, vous rejouerez l'incident.
Après : 2FA et hygiène
Proposez la double authentification sur les comptes qui le peuvent (surtout marchands, B2B). Sur une vitrine simple, au moins tous les admins.
Documentez la date du reset forcé dans le registre et le constat. C'est une mesure « appropriée » au sens des obligations, pas un gadget.
Créer un espace si le site n'est pas encore refermé. Le reset sur un site ouvert est une course perdue.
- Reset imposé, pas suggéré.
- Sessions tuées le même jour.
- Porte d'entrée fermée, sinon recommencer.