mysql如何检查数据库中是否存在无密码或弱密码账号_执行安全扫描查询

MySQL数据库安全审计：如何揪出那些“不设防”的账号？

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

数据库安全的第一道防线，往往就败在几个疏于管理的账号上。空密码、弱密码、匿名用户……这些配置上的“小疏忽”，常常成为数据泄露的“大缺口”。今天，我们就来聊聊，如何系统性地给MySQL做一次“账号体检”，把那些不设防的入口一个个找出来。

检查 MySQL 中是否存在空密码账号

你知道吗？MySQL确实允许创建密码为''（空字符串）的账号，这种账号无需任何凭证就能直接登录，风险等级堪称“高危”。虽然从5.7版本开始，默认策略已经禁止了空密码，但在那些历史遗留的旧实例，或者有人手动改过mysql.user系统表的环境里，这类“隐形冲击波”依然可能存在。

怎么确认？运行下面这条查询语句，真相一目了然：

SELECT host, user, authentication_string FROM mysql.user WHERE LENGTH(TRIM(authentication_string)) = 0 OR authentication_string IN ('', '*');

这里有几个关键点需要留意：在MySQL 5.7及以上版本，密码哈希值存储在authentication_string字段里，通常是一串长字符。如果这个字段的值是''（空），甚至是旧版本中用作占位符的'*'，那基本可以断定，这个账号要么没设密码，要么密码就是空的。

• 使用TRIM()函数是个好习惯，它能防止有人用空格伪装成非空密码，蒙混过关。
• 别再依赖已经过时的password字段了，尤其是在8.0版本它已被移除。
• 执行这条查询，你需要root账号，或者至少拥有SELECT ON mysql.*的权限。

识别常见弱密码哈希值（如 '123456'、'password'）

MySQL当然不会存储明文密码，但这不代表弱密码就无迹可寻。因为密码的哈希算法是固定的，我们可以把那些常见弱口令（比如“123456”、“password”）对应的哈希值提前算好，然后去数据库里“按图索骥”。

举个例子，明文'123456'在mysql_native_password认证插件下，其哈希值固定为*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9。那么，筛查起来就很简单了：

SELECT host, user, plugin, authentication_string FROM mysql.user WHERE authentication_string IN (
  '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9', -- 123456
  '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19', -- password
  '*AAB0484EA8719F782B12F5E181243E343312410A'  -- 12345678
);

• 哈希值匹配必须严格区分大小写，一个字母都不能错。
• 不同认证插件的哈希算法天差地别。用mysql_native_password算出来的哈希，跟caching_sha2_password算出来的完全不是一回事，千万不能混用。尤其是在MySQL 8.0默认启用新插件的环境下，筛查弱密码需要根据实际使用的插件重新计算哈希值。
• 对于生产环境，如果使用了caching_sha2_password插件，强烈建议关闭其自动生成RSA密钥的明文传输模式，并配置好RSA加密，进一步堵住传输过程中的风险。

检查匿名用户和通配符主机账号

除了弱密码，还有两类账号配置需要特别警惕：匿名用户和主机范围过于宽松的账号。匿名用户（user = ''）意味着登录时连用户名都不用输；而主机设为'%'（允许任何IP连接）的账号，如果再配个弱密码，无异于向整个互联网敞开了大门。

运行下面这条查询，把这些潜在的风险入口一并扫出来：

SELECT host, user, authentication_string FROM mysql.user WHERE user = '' OR host = '%' OR (host = 'localhost' AND LENGTH(TRIM(authentication_string)) = 0);

• 只要查询结果不是空的，就说明存在匿名用户，必须立即处理。
• host = '%'本身是一种灵活的配置，但它的危险性完全取决于和它搭配的密码强度。一旦密码薄弱，风险便指数级上升。
• 特别要小心那些本地的运维脚本，有时它们会创建一个'root'@'localhost'账号却忘了设密码，这种“灯下黑”的情况也需要单独排查。

扫描后必须立即处理的三件事

查出问题只是第一步，更重要的是后续的“外科手术”。以下这三项操作，缺一不可：

• 强制重置密码：对于有保留必要但密码薄弱的账号，立即用ALTER USER 'u'@'h' IDENTIFIED BY 'StrongPass!2024';（8.0+）或SET PASSWORD FOR 'u'@'h' = PASSWORD('...');（5.7）命令，将其密码改为强密码。
• 删除无用账号：对于那些确定不再使用的匿名用户或测试账号，果断执行DROP USER 'u'@'h';。这里有个细节：在MySQL 5.7及以上版本，DROP USER命令会同步清理权限表，比直接去mysql.user表里执行DELETE要安全、干净得多。
• 刷新权限：执行FLUSH PRIVILEGES;。不过要注意，这个操作仅在直接修改mysql.user系统表后才必须执行。如果你用的是标准的ALTER USER或DROP USER命令，权限变更会自动生效，无需额外刷新。

最后必须提醒一点：虽然MySQL 8.0.25+版本默认启用了validate_password组件来校验密码强度，但它只管“新人”（新建或修改的密码），管不了“旧账”（存量弱密码）。这意味着，定期的、主动的人工扫描与审计，依然是保障数据库账号安全不可替代的核心环节。千万别把希望完全寄托在默认配置上。