为什么MySQL 8.0推荐使用新caching_sha2_password插件？

MySQL 8.0默认使用caching_sha2_password而非mysql_native_password，因其强制盐值、5000轮SHA256迭代及RSA加密传输，彻底解决后者无盐哈希、明文协商和易被重放等真实安全漏洞。

caching_sha2_password 不是“推荐用”，而是 MySQL 8.0 的默认认证插件——它取代 mysql_native_password 是因为后者在安全上已不可接受。

它解决的是真实被利用的漏洞，不是理论风险

mysql_native_password 存储密码的方式是 SHA1(SHA1(password))，没有盐值：

• 相同密码 → 完全相同的哈希值，攻击者扫一眼 mysql.user 表就能发现哪些账号共用密码
• 没有迭代轮数，GPU 几分钟就能跑完常见密码字典
• 握手阶段 challenge-response 数据可被截获重放，尤其在未强制 SSL 的内网或跳板机场景

而 caching_sha2_password 强制引入三个硬性防护：

• 每个用户生成独立 20 字节随机 salt，写入 authentication_string 字段前缀
• 密码哈希 = SHA256(salt + password)，再迭代 5000 轮 SHA256
• 非 SSL 连接下，必须通过服务器 RSA 公钥加密传输中间值（需客户端显式允许 allowPublicKeyRetrieval=true）

它的“caching”只加速验证，不降低安全水位

名字里的 “caching” 指服务端内存缓存已成功认证的凭据对，仅用于短时间内的重复连接复用：

• 首次连接耗时 ≈ sha256_password（都要做 5000 轮 SHA256）
• 缓存命中时耗时下降 60%~80%，TTL 默认 300 秒，重启即失效
• 缓存不存明文、不存原始哈希，只存一次校验通过后的会话标识

兼容性问题不是插件的缺陷，而是客户端没走对协议路径

报错 Public Key Retrieval is not allowed 或 Unknown system variable 'caching_sha2_password'，通常是因为：

• JDBC 驱动版本 < 8.0.9，不支持 RSA 密钥交换流程
• Navicat ≤ 12.1 使用旧版 libmysqlclient，无法处理公钥协商
• PHP 的 mysqli 和 PDO_MySQL 扩展至今（2026 年）仍未原生支持该插件
• Docker 容器内 client lib 版本滞后（如 Ubuntu 20.04 自带的 MySQL client < 8.0.28）

真正容易被忽略的点是：这个插件和 SQL 注入完全无关。它只管“你是不是合法用户”，不管“你执行的 SQL 是否危险”。哪怕你用 caching_sha2_password 登录成功，拼接字符串的查询照样被注入。