mysql中权限设置中的密码策略与加密

MySQL 8.0+默认启用validate_password插件且策略为MEDIUM，强制密码强度校验；ALTER USER ... IDENTIFIED WITH指定认证插件并重置哈希值；密码传输加密由SSL/TLS控制，与哈希算法无关。

MySQL 8.0+ 默认密码策略强制启用 validate_password

MySQL 8.0 开始，validate_password 插件默认启用，且策略等级为 MEDIUM。这意味着即使你用 CREATE USER ... IDENTIFIED BY '123'，也会报错：ERROR 1819 (HY000): Your password does not satisfy the current policy requirements。

这不是“加密方式”问题，而是密码强度校验拦截在认证前。常见误操作是以为改了 default_authentication_plugin 就能绕过，其实无关。

• 检查是否启用：

  SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'validate_password';

• 临时禁用（仅测试环境）：

  UNINSTALL PLUGIN validate_password;

• 调低策略（生产慎用）：

  SET GLOBAL validate_password.policy = LOW;

  （可选值：LOW/MEDIUM/STRONG）

ALTER USER ... IDENTIFIED WITH mysql_native_password BY 'xxx' 的真实作用

这条语

句常被误解为“指定加密方式”，实际它只做两件事：指定认证插件、重置密码哈希值。MySQL 不存储明文密码，所有密码都以哈希形式存入 mysql.user.authentication_string 字段。

关键点在于：mysql_native_password 对应的是 SHA1(SHA1(password)) 哈希（旧协议），而 caching_sha2_password（MySQL 8.0 默认）用的是 SHA2-256 + salt + 多轮迭代，更安全但部分老客户端不兼容。

• 查看用户当前认证插件：

  SELECT User, Host, plugin FROM mysql.user WHERE User = 'your_user';

• 降级兼容旧客户端：

  ALTER USER 'appuser'@'%' IDENTIFIED WITH mysql_native_password BY 'P@ssw0rd2025';

• 注意：执行后必须 FLUSH PRIVILEGES; 才生效（虽然多数情况自动刷新，但显式执行更稳）

密码哈希值直接写入 authentication_string 的风险与限制

MySQL 允许跳过密码校验，用哈希值直接赋值，例如：

UPDATE mysql.user SET authentication_string = '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9' WHERE User = 'test';

。但必须满足三个条件：

• 哈希值格式必须严格匹配对应插件要求（mysql_native_password 是 41 字符星号开头，caching_sha2_password 是 72 字符，以 $A$ 或 $B$ 开头）
• 不能在未禁用 validate_password 时这么做——插件会拒绝空密码或非法哈希格式
• 修改后必须 FLUSH PRIVILEGES;，且该用户下次登录时，MySQL 不再校验原始密码，而是比对传入密码经相同算法生成的哈希

这种操作极少需要，容易因哈希格式错误导致用户锁死；调试时可用 SELECT PASSWORD('xxx')（已弃用）或 SHA1(UNHEX(SHA1('xxx'))) 模拟旧插件哈希，但不推荐用于生产。

客户端连接时的加密协商取决于 ssl_mode 和服务器配置，和密码哈希无关

密码本身是否“传输加密”，由 TLS/SSL 层控制，和 authentication_string 存什么哈希完全无关。比如即使你用 mysql_native_password，只要连接时加了 --ssl-mode=REQUIRED，密码在链路上仍是加密传输的。

真正影响密码安全的是两个层面：

• 存储层：哈希算法强度（caching_sha2_password > mysql_native_password）
• 传输层：是否启用有效 SSL（看 have_ssl 变量和 ssl_ca 配置，不是只开 skip_ssl=OFF 就算启用）

很多团队卡在“为什么开了 SSL 还提示不安全”，其实是客户端没配 --ssl-ca 或服务端 require_secure_transport=ON 后没同步更新客户端信任链。