Trouver un mot de passe root MySQL oublié dans l'historique du shell

Les shells interactifs conservent une trace de ce qui a été tapé. Bash écrit chaque commande dans ~/.bash_history, et la commande interne history affiche cette liste. Cette fonctionnalité est censée vous éviter de retaper des commandes, mais elle a un effet de bord : tout ce que vous passez en argument, y compris un mot de passe, est enregistré tel quel et reste présent longtemps après la fin de la commande.

Le coupable classique est le client MySQL. Écrire mysql -uroot -pR00t!Db_2026 shop transmet le mot de passe au programme sur la ligne de commande. Il n'y a pas d'espace entre -p et la valeur, donc tout le jeton constitue l'identifiant. Cette ligne se retrouve désormais dans le fichier d'historique, lisible par quiconque opère ensuite en tant que cet utilisateur. Plusieurs autres outils présentent le même défaut, ce qui explique que beaucoup avertissent désormais que fournir un mot de passe sur la ligne de commande n'est pas sûr.

Du point de vue d'un attaquant, c'est l'un des gains les moins coûteux disponibles. Pas besoin de lire un fichier de configuration, d'élever ses privilèges ou de casser une quelconque cryptographie : il suffit de lancer history et de lire. Comme sudo est une impasse dans ce scénario, l'historique est exactement le genre d'artefact peu coûteux et à forte valeur qu'un véritable opérateur vérifie en premier après avoir pris pied sur une machine.

• Chercher le mot de passe dans des fichiers. Il n'a jamais été écrit dans un fichier ici : la valeur n'est apparue que sur une ligne de commande, donc history est le bon outil, pas cat.
• Se tourner vers sudo. sudo est une impasse dans ce scénario ; le gain consiste à lire ce qui est déjà lisible, pas à élever ses privilèges.
• Se tromper sur le début du mot de passe. La valeur suit -p sans espace : R00t!Db_2026, et non le nom de base de données shop qui vient après.
• Supposer que l'historique est effacé. Les opérateurs nettoient rarement leur historique ; la ligne survit généralement jusqu'à ce que quelqu'un l'efface volontairement.

La cause profonde est de placer un secret sur une ligne de commande, quel qu'il soit. Des pratiques plus sûres gardent le mot de passe hors de la liste des processus et du fichier d'historique :

• Utilisez mysql -uroot -p sans valeur pour que le client demande le mot de passe de manière interactive : il n'est alors jamais tapé comme argument.
• Stockez les identifiants dans un fichier ~/.my.cnf protégé avec chmod 600, ou utilisez mysql_config_editor pour les conserver dans un chemin de connexion chiffré.
• Préférez une authentification par socket ou par jeton pour éviter d'avoir besoin d'un mot de passe statique lors des requêtes courantes.
• Effacez régulièrement l'historique sensible et définissez HISTCONTROL=ignorespace pour empêcher les commandes contenant des secrets d'entrer dans le fichier d'historique.

Si un mot de passe est apparu dans l'historique ou dans une liste de processus, considérez-le comme compromis et changez-le : effacer l'historique après coup n'annule pas une lecture qui a peut-être déjà eu lieu.