As a rule, safety is inversely proportional to convenience. Keeping a history of commands that you can navigate in the CLI is very convenient. So does bash, for example. So does MySQL, carefully and line by line writing commands to ~ / .mysql_history in plain text (including passwords). It is possible to reduce the risk or completely avoid leakage if (from more permissible, in my opinion, ways to less permissible):
the user's home directory has access mode 700;
file ~ / .mysql_history has access mode 600;
call the script that cleans the ~ / .mysql_history file from the "extra" entries;
“Manually” clean the ~ / .mysql_history file from the “extra” entries;
delete the file ~ / .mysql_history (this option suggests SecurityFocus);
~ / .mysql_history is a symbolic link to / dev / null (no history is kept).
From the point of view of the DBMS, this is not a security problem, since in the query history there may be much more valuable information than passwords (payment information, for example), so developers do not take care of such exceptions at the command history level.
Actually, why this topic was touched. What other options are there?
Bonus track . When addressing the issue of MySQL security, I want to note that I often observe root account data in backup scripts using mysqldump. A very common mistake, and it’s not so difficult to create a special user to unload the bases with a couple of commands:
GRANT SELECT, LOCK TABLES ON .* TO <user-dumper>@localhost IDENTIFIED BY '<dumper-password>'; FLUSH PRIVILEGES;