MySQL 8.0+ 默认认证插件是 caching_sha2_password,它基于加盐 PBKDF2(5000 轮 SHA256)派生密钥并 AES 加密存储,非直接 SHA256 哈希;须用 ALTER USER 修改密码,禁用手动更新 mysql.user 表。

mysql中加密密码存储与更改密码策略  第1张

MySQL 用户密码默认用 SHA256 还是 caching_sha2_password

MySQL 8.0+ 默认认证插件是 caching_sha2_password,它底层使用 SHA256 哈希,但不是直接存 SHA256(password)——而是用加盐的 PBKDF2 衍生密钥(salt + 5000 轮 SHA256),再经 AES 加密存储。所以不能简单用 SHA256() 函数模拟其哈希值。

查看当前用户插件:

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

  • plugincaching_sha2_password,密码字段 authentication_string 是加密后的二进制 blob(不可逆、不可读)
  • 若为 mysql_native_passwordauthentication_string 是纯 SHA1 哈希(旧协议,不推荐)
  • 不建议手动更新 authentication_string 字段——必须用 ALTER USERSET PASSWORD,否则会破坏认证流程

ALTER USER 安全改密,别碰 mysql.user

直接 UPDATE mysql.user 表不仅无效(MySQL 8.0+ 会忽略),还可能锁表或触发权限异常。正确方式始终走 SQL 命令:

ALTER USER 'admin'@'localhost' IDENTIFIED BY 'NewP@ssw0rd2024!';
  • 该语句自动调用对应插件的密码派生逻辑(如 caching_sha2_password 会生成新 salt 并重算)
  • 如果要强制降级兼容老客户端,可指定插件:
    ALTER USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'legacy_pwd';
  • 执行后需 FLUSH PRIVILEGES;(仅当手动改表后才真需要;正常用 ALTER USER 不必)

应用层连接时密码明文传输?得靠 TLS 或 sha256_password 插件

即使服务端用了强哈希,如果客户端用明文传密码(比如 JDBC URL 没开 SSL),中间人仍能截获。两种缓解路径:

  • 启用 TLS:在连接字符串中加 ?useSSL=true&requireSSL=true(MySQL Connector/J),服务端需配置 ssl-ca/ssl-cert
  • sha256_password 插件(注意不是 caching_sha2_password):它要求客户端用 RSA 公钥加密密码后再传,服务端用私钥解密——前提是服务端已生成密钥对并配置 sha256_password_private_key_path
  • caching_sha2_password 默认走安全通道协商;若连接未加密且无 RSA 密钥,会退回到明文传输(日志里报 Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.

自定义密码策略:靠 validate_password 插件,不是加密逻辑本身

MySQL 不负责“密码强度校验”的加密实现,而是通过插件控制创建/修改密码时的合规性。启用后,ALTER USER 会校验密码是否满足规则:

INSTALL PLUGIN validate_password SONAME 'validate_password.so';

常用参数(写入 my.cnf 或运行时设):

  • validate_password.length:最小长度(默认 8)
  • validate_password.mixed_case_count:至少几个大小写字母(默认 1)
  • validate_password.number_count:至少几个数字(默认 1)
  • validate_password.special_char_count:至少几个特殊字符(默认 1)
  • validate_password.policy:0=LOW(只校验长度)、1=MEDIUM(加字数/数字/特殊符)、2=STRONG(再加字典检查)

这些策略不影响已有密码的哈希方式,只拦住弱密码被设进去。一旦设了强策略,连 root 改密也得遵守——这点常被忽略,导致运维卡住。