Mots de passe en clair dans le site : l'incident double
Si le constat montre un stockage en clair, la notification et l'information sont quasi certaines. Corrigez le stockage après avoir fermé l'entrée, pas seulement le fichier PHP qui affichait les comptes. C'est une dette distincte de l'intrusion.
Si le constat montre un stockage en clair, la notification et l'information sont quasi certaines. Corrigez le stockage après, pas seulement l'entrée. C'est une dette distincte.
Ce que « en clair » veut dire
Le secret du client ou du compte interne est lisible dans la base, un export, un CSV, un plugin, un mail de « bienvenue qui rappelle le mot de passe ». Pas un hash. Pas un jeton à usage unique. Une chaîne réutilisable telle quelle.
Un chiffrement réversible dont la clé est dans le même `wp-config` est souvent équivalent, pour l'attaquant qui a déjà le serveur. Le constat le qualifie honnêtement : « récupérable par quiconque lit les fichiers de config ».
Les questions secrètes en clair, les PIN boutique, les mots de passe SMTP du site dans une option : même famille, destinataires différents.
Pourquoi c'est un incident double
L'intrusion est un événement. Le stockage en clair est une mesure inadaptée, souvent ancienne, parfois « pour que le support puisse relire ». Les deux se cumulent : qui a lu la table a les comptes. Les 72 heures et l'information deviennent le scénario par défaut, sauf périmètre minuscule et données non authentifiantes — rare dès qu'il y a un login.
Corriger seulement l'entrée (backdoor) et laisser le clair, c'est garantir qu'une prochaine lecture reproduira le même RGPD.
C'est distinct du debate « hash faible » : là, il n'y a même pas de hash. Voir aussi forcer le reset.
- Intrusion : accès non autorisé.
- Clair : gravité intrinsèque dès lecture.
- Deux lignes dans le constat, deux remédiations.
Où ça se trouve encore
Vieux développements sur mesure, plugins de « membres », exports Excel du stagiaire, CRM qui synchronise le mot de passe, emails transactionnels « voici votre mot de passe », fichiers `.sql` dans les backups web. Prestashop / WordPress cœurs officiels hashent ; les add-ons et les ponts, pas toujours.
Les journaux applicatifs qui enregistrent le POST du login. Les tickets support avec le secret copié-collé. Cherchez ces canaux dans le même audit que la table.
Un champ `password` qui fait 8 caractères lisibles n'est pas un hash bcrypt. Si vous ne savez pas lire, faites lire. N'inventez pas « c'est chiffré » parce que l'écran affiche des puces.
Constats, CNIL, personnes
Le constat écrit : « stockage en clair constaté sur telle table / tel export ». C'est une phrase qui pèse. Elle oriente le risque vers le haut. La page fuite et le guide s'appliquent sans subtilité de « peut-être que le hash tient ».
Informez : leurs secrets ont pu être lus, ils doivent en changer ici et partout où ils étaient les mêmes. Une phrase, pas un roman. Réutilisation.
Documentez dans le registre la dette et la date de correction du stockage. Les obligations TPE parlent de mesures appropriées : le clair après 2020 sur un login public est difficile à défendre.
Corriger le stockage sans tout casser
Après fermeture de l'entrée, pas pendant le chaos des fichiers. Plan : reset forcé (les gens choisissent un secret neuf), écriture uniquement hashée désormais, plus aucun affichage ni email du secret, plus d'export clair.
Migrer des clairs vers des hashes sans reset est possible techniquement ; après une lecture, ça ne suffit pas : l'attaquant a déjà les clairs. Reset quand même.
Testez le login, le mot de passe oublié, les apps liées. Un correctif qui casse toute la boutique n'est pas une excuse pour rester en clair « encore un mois ».
Exports, emails, sauvegardes
Les backups qui contiennent la colonne claire sont des copies de la fuite. Isolez-les, restreignez l'accès, planifiez une rétention courte une fois le juridique et l'assurance servis. Les sauvegardes hors serveur ne doivent plus recopier le clair une fois le schéma corrigé.
Rappelez les CSV envoyés par WeTransfer en 2022. Vous ne les « rappelez » pas tous ; vous le notez comme limite du constat.
Les boîtes qui ont reçu « voici votre mot de passe » : fenêtre d'exposition plus large que l'intrusion. Une phrase dans l'information des personnes.
Ce qu'on dit, concrètement
Aux personnes : nous stockions votre mot de passe d'une façon insuffisante ; un accès non autorisé l'a rendu lisible ; changez-le ici et ailleurs. Sans détail d'implémentation.
À la CNIL : nature (authentifiants en clair), mesure (abandon du clair, reset). Pas besoin d'un cours. Aux assureurs : la même chose, datée. Communication publique : plus courte, sans se vanter d'une « architecture zero trust ».
En interne : qui a demandé le clair « pour le support » — pour que ça ne revienne pas. Sans chasse aux sorcières le jour J.
Ne pas confondre avec un champ debug
Un site en `WP_DEBUG` qui logue des POST n'est pas « le métier stocke en clair », mais c'est une fuite de secrets dans les logs. Traitez-le : couper le debug public, purger les logs exposés. Autre article possible dans votre lot technique ; ici, le critère est : un humain support pouvait-il lire le mot de passe du client dans l'admin ou un export ?
Les tokens d'API en clair dans la base sont une cousine. Révoquer + ne plus les réafficher.
Si vous déléguez, créer un compte pour le site ; exigez que le constat mentionne explicitement clair vs hash. C'est la phrase qui oriente tout le RGPD.
- Constater le clair par écrit.
- Reset + nouveau stockage.
- Copies et emails anciens dans les limites.