mysql 5.7+通过authentication_string字段长度和哈希值可识别弱口令：长度非41位（mysql_native_password）或72位（caching_sha2_password）即提示极短原始密码；空值、'*'或1–30位哈希可初筛；匹配预计算哈希可确证；还需结合password_expired、password_last_changed及validate_password策略综合判断长期弱口令风险。
MySQL 5.7+ 不存明文密码，但 authentication_string 字段长度和值能直接暴露弱口令风险——长度远小于 41 位（mysql_native_password）或 72 位（caching_sha2_password），基本可判定原始密码极短；哈希值匹配已知弱口令的预计算结果，则是确凿证据。
查空密码和极短哈希值（最快速初筛）
空密码、单字符密码、未设密码的账号在生产环境属于高危配置，必须优先识别。重点不是“有没有密码”，而是 authentication_string 是否为空、为占位符或明显过短。
SELECT host, user, plugin, authentication_string FROM mysql.user WHERE LENGTH(TRIM(authentication_string)) = 0 OR authentication_string IN ('', '*');- 该语句能捕获
''（空字符串）、'*'（旧版未加密占位符）两类典型无密状态 -
TRIM()防止用空格填充伪装成非空；不要用password字段（8.0 已移除） - 若返回结果中
authentication_string长度为 1～30 位（如'*1'或'*0'），基本可断定原始密码是''、'1'、'0'等超弱口令
比对已知弱口令哈希值（精准确认）
明文虽不可见，但 MySQL 认证插件哈希逻辑固定，可预先生成常见弱口令的哈希串做精确匹配。关键前提是：先确认目标用户用的是哪个插件，再用对应哈希值筛查。
- 先查插件：
SELECT user, host, plugin FROM mysql.user;，重点关注mysql_native_password和caching_sha2_password - 只查
mysql_native_password用户：SELECT host, user, authentication_string FROM mysql.user WHERE plugin = 'mysql_native_password' AND authentication_string IN ('*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9', '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19'); -
'*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9'是'123456'的哈希，'*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19'是'password'的哈希 - 不同插件哈希不可混用：
caching_sha2_password下的'123456'是 Base64 编码的 SHA256 哈希（72 位），不能拿上面 41 位值去比
结合密码策略字段判断长期弱口令隐患
有些账号虽未被爆破，但因长期不更新、策略宽松，实际已沦为“静默弱口令”。这类风险不会体现在哈希值上，需从时间戳和策略配置交叉验证。
- 查长期未改且已过期的账号：
SELECT host, user, password_expired, password_last_changed FROM mysql.user WHERE password_expired = 'Y' AND password_last_changed - 查密码策略是否形同虚设：
SHOW VARIABLES LIKE 'validate_password%';，若validate_password_length≤ 6 或validate_password_policy= 'LOW'，说明系统允许极弱密码注册 - 注意：即使
authentication_string是合规长度的哈希，若策略宽松 + 用户长期不改，仍可能沿用初始弱口令（如安装时设的'root'）
真正难处理的不是哈希值能直接匹配的弱口令，而是那些哈希长度合规、策略也开着，但用户用生日+手机号拼接、或全站统一密码的账号——它们躲得过自动扫描，却扛不住社工或撞库。所以查完 authentication_string，一定得同步看 password_last_changed 和业务侧密码管理规范。
