mysql登录安全性核心在于认证插件，推荐使用caching_sha2_password。1.检查默认插件：show variables like 'default_authentication_plugin'; 2.修改my.cnf配置default_authentication_plugin=caching_sha2_password并重启；3.升级现有用户：alter user 'user'@'host' identified with caching_sha2_password by 'password'; 4.确保客户端驱动支持sha-256；此外还需ip白名单、ssl/tls加密、最小权限原则、日志审计、强密码策略及堡垒机等多方面措施共同保障安全。
MySQL的登录安全性，远不止设个复杂密码那么简单，它更深层次地取决于底层使用的认证插件。要真正提升安全性，核心在于抛弃那些老旧、脆弱的认证机制，转向更现代、更健壮的方案。
解决方案
提升MySQL登录安全性的直接且有效方案是采用更强的认证插件，特别是MySQL 8.0及更高版本默认的
caching_sha2_password。这个插件基于SHA-256加密算法，并且结合了客户端缓存机制，既安全又兼顾性能。它替代了之前版本中广泛使用的、安全性相对较低的
mysql_native_password。
具体操作上，你需要：
检查当前MySQL实例的默认认证插件：
SHOW VARIABLES LIKE 'default_authentication_plugin';
如果结果是
mysql_native_password，那么你就知道需要动手了。
修改MySQL服务器的默认认证插件： 可以在
my.cnf（或
my.ini）配置文件中，在
[mysqld]段下添加或修改：
default_authentication_plugin=caching_sha2_password
然后重启MySQL服务。这会影响所有新创建的用户。
升级现有用户的认证插件： 对于已经存在的用户，需要逐一修改。比如，将
your_user的认证方式升级：
ALTER USER 'your_user'@'localhost' IDENTIFIED WITH caching_sha2_password BY '新密码'; FLUSH PRIVILEGES;
记住，修改后客户端连接可能需要更新驱动程序或进行相应配置，否则会连接失败。这是个常见的坑，很多人改了服务器端，却忘了客户端的兼容性问题。
为什么MySQL默认的mysql_native_password
不够安全？
说实话，
mysql_native_password这个认证插件，它在密码哈希处理上确实有点“老旧”了。它主要依赖的是SHA-1算法，而且其实现方式使得它在面对现代的暴力破解、字典攻击甚至是彩虹表攻击时，显得力不从心。简单来说，它生成的哈希值，相对容易被逆向推导出原始密码，尤其是在密码复杂度不够高的情况下。
我个人觉得，它之所以能存在这么久，很大程度上是出于历史兼容性的考虑。很多老旧的应用系统，甚至是一些你意想不到的商业软件，可能还在默默地使用着这个插件。当你尝试升级到更安全的认证方式时，第一个遇到的障碍往往不是MySQL本身，而是那些“古董级”的客户端驱动。这让人挺无奈的，为了兼容性，我们不得不牺牲一部分安全性。但从长远看，淘汰它是必然的。
如何将MySQL用户认证方式升级到caching_sha2_password
？
升级到
caching_sha2_password，这事儿得一步步来，不能心急。
首先，你得确认你的MySQL版本是不是8.0或更高。如果是，那恭喜你，这个插件是默认且内置的。如果是老版本，比如5.7，那你就得考虑升级MySQL本身了。
实际操作上，你可能需要这样做：
检查全局设置：
SHOW VARIABLES LIKE 'default_authentication_plugin';
如果这里显示的是
mysql_native_password，那么新创建的用户默认还是不安全的。
修改全局默认插件： 为了让以后创建的用户默认就安全，最彻底的办法是在
my.cnf配置文件里，找到
[mysqld]段，然后加上或修改这一行：
default_authentication_plugin=caching_sha2_password
改完记得重启MySQL服务。这一步是治本。
处理现有用户： 对于那些已经存在的、还在用老插件的用户，你需要逐个“改造”他们。比如，有个用户叫
app_user，密码是
old_password，你想给它换成
new_strong_password并升级认证方式：
ALTER USER 'app_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'new_strong_password'; FLUSH PRIVILEGES;
这里需要特别注意，
ALTER USER命令会同时修改密码和认证插件。如果你不想改密码，那可能得先获取到当前密码哈希，再重新设置，或者更直接地，告诉用户他们需要更新密码。
客户端兼容性问题： 这是最容易被忽略但又最致命的一环。
caching_sha2_password需要客户端的驱动程序（比如Java的Connector/J、Python的mysql-connector-python等）支持SHA256密码认证。很多老版本的驱动并不支持。如果你的应用还在用几年前的驱动，那么很可能在升级MySQL认证插件后，应用就无法连接数据库了。
解决办法通常是：
升级客户端驱动：这是最推荐的。确保你的驱动版本足够新，能够支持caching_sha2_password。 配置客户端连接参数：有些驱动可能需要显式地在连接字符串中指定
allowPublicKeyRetrieval=true（对于Java Connector/J）或者其他类似参数，以允许公钥交换。 临时回退（不推荐）：如果实在无法升级客户端，MySQL也提供了
sha256_password插件，它比
caching_sha2_password稍微简单一些，但仍然比
mysql_native_password安全。或者，你也可以为特定用户暂时保留
mysql_native_password，但这无疑是开了个后门。
除了认证插件，还有哪些方法可以进一步强化MySQL登录安全？
提升MySQL登录安全性，绝不仅仅是换个认证插件这么简单。它是一个系统性的工程，需要多管齐下。
严格的IP白名单和主机限制： 这是最基础也是最有效的防线之一。不要让你的数据库用户可以从任何地方登录。明确指定用户只能从特定的IP地址或主机名进行连接。
CREATE USER 'admin'@'192.168.1.100' IDENTIFIED BY 'strong_password'; GRANT ALL PRIVILEGES ON *.* TO 'admin'@'192.168.1.100';
对于应用连接的用户，也应该限制到应用服务器的IP。这能极大程度地减少攻击面。
强制使用SSL/TLS加密连接： 即使密码认证再强，如果数据在传输过程中是明文的，那也形同虚设。启用并强制SSL/TLS连接，可以加密客户端与MySQL服务器之间的所有通信。 你可以在创建用户时要求SSL：
CREATE USER 'secure_user'@'%' IDENTIFIED BY 'password' REQUIRE SSL;
或者在
my.cnf中配置SSL证书并强制所有连接使用。这能有效防止中间人攻击和数据窃听。
最小权限原则（Least Privilege）： 给用户分配权限时，只授予他们完成工作所必需的最小权限。例如，一个Web应用用户通常只需要对特定数据库的SELECT、INSERT、UPDATE、DELETE权限，而不需要DROP TABLE或GRANT权限。
GRANT SELECT, INSERT, UPDATE, DELETE ON your_db.* TO 'app_user'@'localhost';
避免使用
GRANT ALL PRIVILEGES，除非是管理用户。权限过大是很多安全漏洞的根源。
启用并定期审计日志： MySQL的错误日志、慢查询日志、二进制日志以及审计日志（如果启用插件）都能提供宝贵的信息。特别是审计日志，可以记录谁在什么时候做了什么操作，包括登录尝试和失败。定期检查这些日志，可以帮助你发现异常登录行为或潜在的攻击。
实施强密码策略： 虽然认证插件本身提供了更强的哈希算法，但用户密码本身的强度依然至关重要。利用MySQL的密码验证插件（
validate_password），可以强制用户设置满足复杂性、长度和过期要求的密码。
考虑堡垒机/跳板机： 对于生产环境的数据库，直接暴露给开发人员或运维人员的风险很高。通过引入堡垒机或跳板机作为中间层，可以集中管理所有对数据库的访问，并记录操作日志。这增加了另一层安全控制和审计能力。
这些方法结合起来，才能构建一个相对完善的MySQL登录安全体系。毕竟，安全从来都不是一劳永逸的，它是一个持续改进的过程。
