MySQL 5.7如何应对针对mysql_native_password的攻击

MySQL 8.0 升级后应淘汰 mysql_native_password，因其使用无 salt 的 SHA1 易被爆破且已弃用；须批量改用 caching_sha2_password，并清理配置中残留的旧 default_authentication_plugin 设置。

mysql 5.7如何应对针对mysql_native_password的攻击_升级到8.0

mysql_native_password 本身不是攻击面，而是旧认证协议；真正的问题是：升级到 MySQL 8.0 后，默认启用 caching_sha2_password，但老客户端连不上——这时有人误以为“必须保留 mysql_native_password 才安全”，结果反而暴露了更弱的认证路径。

别绕弯子：MySQL 5.7 升级到 8.0 的核心安全动作，不是“加固 mysql_native_password”，而是主动淘汰它，并确保所有连接走现代协议。

为什么不能继续用 mysql_native_password？

mysql_native_password 使用 SHA1 哈希 + challenge-response，不带 salt，可被离线字典爆破；MySQL 官方自 8.0 起将其标记为“deprecated”，并在后续版本中计划移除。它不是“不够强”，而是“设计上已过时”。

不支持密码轮换后的密钥派生（如 PBKDF2）
无法抵御重放或中间人（即使走 TLS，认证阶段仍脆弱）
PHP mysqlnd 5.0.12 以下、Python MySQLdb、旧 JDBC 驱动报错 Authentication plugin 'caching_sha2_password' cannot be loaded，本质是驱动太老，不是协议该留着

升级后立刻执行的三步认证修复

升级完成、MySQL 8.0 启动成功后，第一件事不是改应用，而是收紧数据库侧配置：

登录 MySQL：mysql -u root -p（用原 5.7 密码，8.0 会自动兼容旧插件登录）
批量切换所有业务用户（含 root）：ALTER USER 'user_name'@'host' IDENTIFIED WITH caching_sha2_password BY 'new_strong_pwd';
在 /etc/my.cnf 或 /etc/my.cnf.d/mysql-server.cnf 的 [mysqld] 段加：default_authentication_plugin=caching_sha2_password（防止新建用户又掉回 mysql_native_password）

注意：FLUSH PRIVILEGES; 不需要——ALTER USER 已即时生效。

Work Productivity Word Mail Workflow Helper

构建并排查Microsoft Word邮件合并及DOCX模板工作流，使用合并域、内容控件、文档属性、重复区块、数据等

下载

客户端不升级？那就只给最小权限的兼容账号

真有短期无法升级的客户端（比如嵌入式设备固件、老旧监控脚本），不要全局降级，而是单独建一个受限账号：

新建账号限定 IP 和用途：CREATE USER 'legacy_app'@'192.168.10.5' IDENTIFIED WITH mysql_native_password BY 'pwd_2026!';
只赋必要库表 SELECT 权限：GRANT SELECT ON app_db.orders TO 'legacy_app'@'192.168.10.5';
禁用远程 root 登录：DROP USER 'root'@'%';，只留 'root'@'localhost' 且强制用 caching_sha2_password

这种账号必须设短过期时间（PASSWORD EXPIRE INTERVAL 90 DAY），并记录在运维台账里——它不是方案，是临时补丁。