MySQL 8.0+默认启用validate_password插件且策略为MEDIUM,强制密码强度校验;ALTER USER ... IDENTIFIED WITH指定认证插件并重置哈希值;密码传输加密由SSL/TLS控制,与哈希算法无关。
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_nati
ve_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)have_ssl 变量和 ssl_ca 配置,不是只开 skip_ssl=OFF 就算启用)很多团队卡在“为什么开了 SSL 还提示不安全”,其实是客户端没配 --ssl-ca 或服务端 require_secure_transport=ON 后没同步更新客户端信任链。