MySQL VALIDATE_PASSWORD_STRENGTH 怎样评估候选密码

我第一次把密码强度提示接到注册流程时，最容易误解的是：拿到一个整数分数，并不等于 MySQL 已经替我决定“这个密码一定能创建账户”。VALIDATE_PASSWORD_STRENGTH() 更适合做候选密码的强度评估；账户最终能否通过，还要看 validate_password 组件、当前策略，以及账户使用的认证方式。

MySQL 官方地址：https://dev.mysql.com/doc/refman/8.4/en/validate-password.html

这个函数返回 0 到 100 的整数，0 表示弱，100 表示强。实际接入时，我会先确认组件状态，再把分值和策略信息一起交给应用层，而不是把某个分数硬编码成 MySQL 的默认放行线。

先确认函数不是“固定返回 0”

如果 validate_password 组件没有安装，相关系统变量不可用，VALIDATE_PASSWORD_STRENGTH() 会一直返回 0。这个 0 表示当前环境没有完成密码强度组件的评估能力，不能直接解释成“候选密码特别弱”。

-- 观察密码校验组件暴露的策略变量；没有结果时先确认组件安装状态
SHOW VARIABLES LIKE 'validate_password%';

-- 只评估候选值，不创建账户，也不修改任何密码
SELECT VALIDATE_PASSWORD_STRENGTH('N0Tweak$_@123!');

示例中的字符串只是演示占位符，不应直接用于真实账户。生产环境还要避免把用户输入写入 SQL 日志、应用日志或埋点。这个函数的输入是候选值，调用它本身不会替账户保存密码。

分值怎么读：它是强度结果，不是默认阈值

官方函数只规定返回 0 到 100 的整数，并没有把 60、80 或 90 定义成所有系统都适用的“合格线”。因此我会把它当作用户体验反馈：分值偏低时提示用户增加长度和复杂度，分值较高时允许进入下一步；真正的业务阈值由应用自己定义，并写进产品规则。

-- 一次取出多个候选的评分，便于开发阶段比较策略反馈
SELECT
  VALIDATE_PASSWORD_STRENGTH('short') AS short_score,
  VALIDATE_PASSWORD_STRENGTH('Longer_Example_42!') AS longer_score;

-- 只读取策略配置，不把候选密码拼接进日志或审计文本
SHOW VARIABLES WHERE Variable_name IN (
  'validate_password.policy',
  'validate_password.length',
  'validate_password.number_count',
  'validate_password.mixed_case_count',
  'validate_password.special_char_count',
  'validate_password.check_user_name'
);

分值和策略要分开看。默认的 MEDIUM 策略除了长度，还会要求数字、小写、大写和特殊字符；LOW 主要检查长度；STRONG 还会在配置字典文件时检查长度至少为 4 的子串。长度、字符类别和字典规则可以通过相应变量调整，所以同一候选值在不同环境得到的结论不能简单横向搬运。

不要把函数评分和账户拒绝逻辑混为一谈

当语句通过明文给账户设置密码时，ALTER USER、CREATE USER 和 SET PASSWORD 会按当前密码策略检查，并可能返回 ER_NOT_VALID_PASSWORD。而函数只是评估传入的候选值，特别适合在注册表单或后台改密页面中提供即时提示。

-- 让应用先获得候选密码的分值；这里只展示评估，不执行账户变更
SELECT VALIDATE_PASSWORD_STRENGTH('User_Input_Example_42!') AS score;

-- 账户变更会再次受到当前策略约束；不要把示例密码用于真实账户
ALTER USER 'demo_user'@'localhost'
  IDENTIFIED BY 'User_Input_Example_42!';

还有一个容易漏掉的边界：账户使用外部认证插件时，密码管理由外部凭据系统负责，MySQL 内部的账户密码校验限制不适用于那条外部存储链路；但 VALIDATE_PASSWORD_STRENGTH() 本身仍然可以作为独立评估函数使用。换句话说，先确认凭据到底由谁保存，再决定这次分数提示应该放在哪一层。

应用侧提示怎样更安全、更有用

如果把这个函数接到应用层，我会保留四个小原则：第一，只把分数当作提示信号，不把官方默认阈值想象成存在；第二，服务端和客户端不要回显候选密码；第三，组件缺失时显示“暂时无法评估”，不要显示“密码为 0 分”；第四，用户名检查开启时，提示用户避免正向或反向包含用户名的密码。

提交账户变更时仍然要捕获数据库返回的策略错误，把它转换为用户能理解的提示。这样即时评分负责减少反复提交，数据库策略负责最后一道约束，两层职责不会互相替代。

我会用这张清单做最后判断

1. 组件是否已安装，函数返回 0 时有没有和“弱密码”区分？
2. 当前策略是 LOW、MEDIUM 还是 STRONG，长度、字符类别和字典参数是否被修改？
3. 应用侧阈值是否是自己的产品规则，而不是误称为 MySQL 默认规则？
4. 账户是 MySQL 内部凭据还是外部认证系统，最终拒绝会发生在哪里？
5. 日志、审计和埋点是否完全避免记录候选密码？

一句话概括：用 VALIDATE_PASSWORD_STRENGTH() 得到候选密码的 0–100 评估分值，再结合组件状态、策略变量和认证方式做最终判断。它很适合做注册页面的反馈层，但不能替代账户变更时的策略检查。

相关问题

为什么函数总返回 0？ 先确认 validate_password 组件是否安装；组件未安装时，函数按文档会固定返回 0。

分数达到 80 就一定能创建用户吗？ 不一定。分数不是统一的放行阈值，账户语句还会按当前策略和认证方式执行自己的检查。

能不能只靠前端判断密码强度？ 不建议。前端可以改善体验，服务端和数据库策略仍要保留，且任何一层都不应记录候选密码。