MySQL 8.0 强制默认启用 caching_sha2_password，因 mysql_native_password 依赖已被 NIST 弃用的 SHA1 算法，无盐无迭代、易被爆破和重放，而 caching_sha2_password 提供加盐、5000 轮 SHA256 迭代及 RSA 加密传输三重防护。
MySQL 8.0 不是“推荐用” caching_sha2_password，而是强制默认启用它——因为 mysql_native_password 已被 NIST 弃用、被 MySQL 官方标记为 deprecated，继续用等于主动暴露密码哈希和传输风险。
安全的随机密码生成器。支持自定义长度、字符类型（大写/小写字母、数字、特殊符号），排除相似字符，批量生成。纯 Python 标准库，无需 API 密钥。
mysql_native_password 的真实漏洞不是理论风险
它在生产中已被利用过：
- authentication_string 字段存的是 SHA1(SHA1(password))，无 salt，相同密码 → 完全相同哈希值，扫一眼 mysql.user 就能发现哪些账号共用密码
- 没有迭代轮数，GPU 几分钟就能跑完常见密码字典
- 握手阶段 challenge-response 可被截获重放，尤其在未强制 SSL 的内网或跳板机场景
- SHA1 算法本身已被 NIST 在 2026 年前明确要求停用
caching_sha2_password 的三个硬性防护必须理解清楚
它不是“加了点功能”，而是重构了认证安全基线：
- 每个用户生成独立 20 字节随机 salt，写入 authentication_string 字段前缀
- 密码哈希 = SHA256(salt + password)，再迭代 5000 轮 SHA256
- 非 SSL 连接下，必须通过服务器 RSA 公钥加密传输中间值（客户端需显式允许 allowPublicKeyRetrieval=true）
- 名字里的 “caching” 只加速验证：缓存命中时耗时降 60%~80%，TTL 默认 300 秒，重启即失效；不存明文、不存原始哈希，只存会话标识
报错 “Public Key Retrieval is not allowed” 或 “Unknown authentication method” 的根因
这不是插件问题，是客户端没走对协议路径：
- 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）
- 修改 default_authentication_plugin 配置只影响后续 CREATE USER，对已存在的用户（如 root、appuser）完全无效——真正要改的是每个 user@host 的 plugin 值，靠 ALTER USER ... IDENTIFIED WITH mysql_native_password 逐个覆盖
最容易被忽略的一点：这个插件和 SQL 注入完全无关。它只管“你是不是合法用户”，不管“你执行的 SQL 是否危险”。哪怕你用 caching_sha2_password 登录成功，拼接字符串的查询照样被注入。
