密码出现在MySQL中的多个上下文中。
以下部分提供了一些指导原则 ，使最终用户 和管理员能够确保这些密码的安全并避免暴露这些密码。
此外，validate_password插件可用于强制执行可接受密码的策略。
请参阅"密码验证组件"。
1.密码安全的最终用户指南
MySQL用户应该使用以下准则来保护密码的安全。
当您运行客户端程序以连接到MySQL服务器时，不建议以将密码暴露给其他用户发现的方式指定密码。
此处列出了运行客户端程序时可以用于指定密码的方法，以及对每种方法的风险评估。
简而言之，最安全的方法是让客户端程序提示输入密码，或者在受适当保护的配置文件中指定密码。
使用mysql_config_editor实用程序 ，可以将身份验证凭据存储在名为**.mylogin.cnf的加密登录路径文件**中。
MySQL客户端程序稍后可以读取该文件，以获取连接到MySQL Server的身份验证凭据。
请参阅"mysql_config_editor--mysql配置实用程序"。
在命令行中使用--password=password或-password选项。例如
$> mysql -u francis -pfrank db_name
警告：
这很方便，但不安全。在某些系统上，您的密码对系统状态程序（如ps）可见，其他用户可能会调用这些程序来显示命令行。
MySQL客户端在初始化过程中通常会用零覆盖命令行密码参数。
但是，仍有一个短暂的时间间隔，在此期间该值是可见的。
此外，在一些系统上，这种覆盖策略是无效的，密码对ps仍然可见。（SystemV Unix系统和其他系统可能会遇到这个问题。）
如果您的操作环境设置为在终端窗口的标题栏中显示当前命令，则只要该命令正在运行，即使该命令已滚动到窗口内容区域的视图之外，密码也会保持可见。
在没有指定密码值的情况下，在命令行中使用--password或-p选项。在这种情况下，客户端程序以交互方式请求密码：
$> mysql -u francis -p db_name
Enter password: ********
*字符表示您输入密码的位置。
输入密码时不会显示密码。
这样输入密码比在命令行中指定密码更安全，因为其他用户看不到密码。
但是，这种输入密码的方法仅适用于交互式运行的程序。
如果要从非交互运行的脚本中调用客户端，则无法通过键盘输入密码。
在某些系统上，您甚至可能发现脚本的第一行被读取并被（错误地）解释为密码。
将您的密码存储在配置文件中。
例如，在Unix上，您可以在主目录中.my.cnf文件的[client]部分列出您的密码：
[client]
password=password
为了确保密码的安全，除了你自己，任何人都不应该访问该文件。要确保这一点，请将文件访问模式设置为400或600。例如
$> chmod 600 .my.cnf
要从命令行命名包含密码的特定配置文件，请使用--defaults file=file_name选项，其中file_name是文件的完整路径名。例如
$> mysql --defaults-file=/home/francis/mysql-opts
"使用配置文件"更详细地讨论了配置文件。
在Unix上，mysql客户端将已执行语句的记录写入历史文件
（请参阅"mysql客户端日志记录"）。
默认情况下，此文件名为**.mysql_history**，并在主目录中创建。
密码可以在CREATE USER和ALTER USER等SQL语句中以纯文本形式编写，因此，如果使用这些语句，它们将记录在历史文件中。
为了确保此文件的安全，请使用限制性访问模式， 与前面对**.my.cnf**文件所述的方式相同。
如果您的命令解释器维护历史记录，则保存命令的任何文件都包含在命令行上输入的MySQL密码。
例如，bash使用**~/.bash_history**。任何此类文件都应具有限制性访问模式。
2.密码安全管理员指南
数据库管理员 应使用以下准则来保护密码的安全。
MySQL将用户帐户的密码存储在mysql.user 系统表中。
不应将对此表的访问权限授予任何非管理帐户。
帐户密码可能已过期，因此用户必须重置这些密码。
请参阅"密码管理"和"过期密码的服务器处理"。
validate_password插件可用于对可接受的密码强制执行策略。
请参阅"密码验证组件"。
有权修改插件目录 （plugin_dir系统变量的值）或指定插件目录位置 的my.cnf文件的用户可以替换插件并修改插件提供的功能，包括验证插件。
应该**保护可能写入密码的日志文件等文件。**参见下文
3.密码和日志记录
密码可以写成SQL语句中的纯文本，如CREATE USER、GRANT 和SET PASSWORD 。如果MySQL服务器按照编写的方式记录这些语句，那么任何有权访问日志的人都可以看到其中的密码。
语句日志记录避免将密码写入以下语句的明文：
sql
CREATE USER ... IDENTIFIED BY ...
ALTER USER ... IDENTIFIED BY ...
SET PASSWORD ...
START SLAVE ... PASSWORD = ...
START REPLICA ... PASSWORD = ...
CREATE SERVER ... OPTIONS(... PASSWORD ...)
ALTER SERVER ... OPTIONS(... PASSWORD ...)这些语句中的密码将被重写，使其不会直接出现在写入常规查询日志、慢速查询日志和二进制日志的语句文本中。重写不适用于其他语句。特别是，mysql.user系统表中引用文字密码的INSERT或UPDATE语句会按原样记录，因此应避免使用此类语句。（无论如何，不鼓励直接修改拨款表。）
对于常规查询日志，可以通过使用--log raw选项启动服务器来抑制密码重写。出于安全原因，不建议将此选项用于生产用途。出于诊断目的，查看服务器接收到的语句的确切文本可能很有用。
默认情况下，审核日志插件生成的审核日志文件的内容不会加密，并且可能包含敏感信息，例如SQL语句的文本。出于安全考虑，审核日志文件应写入一个只有MySQL服务器和有正当理由查看日志的用户才能访问的目录。
请参阅"MySQL企业审核安全注意事项"。
如果安装了查询重写插件，服务器接收的语句可能会被重写（请参阅查询重写插件）。
在这种情况下，--log raw选项影响语句日志记录，如下所示：
如果没有**--log-raw**，服务器将记录查询重写插件返回的语句。这可能与收到的声明不同。
使用--log raw，服务器会将收到的原始语句记录下来。
密码重写的一个含义是，无法解析（例如，由于语法错误）的语句不会写入常规查询日志，因为它们不可能是无密码的。
需要记录所有语句（包括有错误的语句）的用例应该使用**--log raw选项**，记住这也可以绕过密码重写。
只有当需要纯文本密码时，才会进行密码重写。
对于具有期望密码哈希值的语法的语句，不会发生重写。
如果为这种语法错误地提供了纯文本密码，则会按照给定的方式记录密码，而无需重写。
要保护日志文件不被不必要的暴露，请将它们定位在限制服务器和数据库管理员访问的目录中。
如果服务器登录到mysql数据库中的表，则只将对这些表的访问权限授予数据库管理员。
副本将复制源服务器的密码存储在其连接元数据存储库中，默认情况下，该存储库是mysql数据库中名为slave_master_info的表。
现在不推荐将数据目录中的文件用于连接元数据存储库，但仍然可以（
请参阅"中继日志和复制元数据存储库"）。
确保只有数据库管理员才能访问连接元数据存储库。
将密码存储在连接元数据存储库中的另一种方法是使用START REPLICA
（或MySQL 8.0.22之前的版本，START SLAVE ）或START GROUP_REPLICATION 语句指定连接到源的凭据。
使用限制访问模式来保护包括日志表 或包含密码的日志文件 的数据库备份。