4. 策略引擎：基于规则与机器学习混合的口令检测模型设计

口令策略的落地，最终要靠一个能跑起来的引擎。纯规则的方式，说白了就是一堆正则表达式堆上去。我见过不少公司，规则写了上百条，结果用户设个「P@ssw0rd!」照样能过——因为规则引擎根本不知道「P@ssw0rd!」其实就是「Password」的简单替换。

那纯机器学习呢？模型倒是聪明，能识别出「iloveyou123」这种弱口令。但你想想看，合规审计的时候，检查员问「你的弱口令判定标准是什么？」你总不能说「模型自己学的，我也说不清」吧？

所以我的做法是——规则兜底，模型提效。两者混在一起，才能既过合规，又防住真正的弱口令。

4.1 为什么非混不可？

先看个真实场景。我在给某金融客户做项目时，他们原有的规则引擎长这样：

if len(password) < 8: reject()
if not re.search(r'[A-Z]', password): reject()
if not re.search(r'[0-9]', password): reject()
if not re.search(r'[!@#$%^&*]', password): reject()

看着挺全吧？结果呢，用户设了个「Aa1!aaaa」，所有规则都过了。但明眼人一看就知道，这口令弱得跟没设一样。规则引擎完全没发现「aaaa」这种重复模式。

反过来，如果只用机器学习模型，又会有两个坑：

• 合规说不清：审计要你解释「为什么这个口令被拒」，模型给不出理由
• 误杀率高：我见过一个模型把「Tr0ub4dor&3」判成弱口令——这其实是个挺强的口令，只是包含了一个常见单词变形

混合模型的好处，就是让规则处理「明确违规」，让模型处理「模糊风险」。各管一摊，互不抢活。

4.2 混合架构长什么样？

我习惯把整个检测流程分成三个阶段。嗯，你可以把它想象成一个漏斗——越往后，筛子越细。

三个阶段各司其职。第一阶段是快车道，几微秒就能决定要不要拒。第二阶段做精细评分，给模型提供上下文。第三阶段才是真正的「智能判断」。

4.3 规则引擎：别小看正则的力量

很多人觉得规则引擎过时了。我不这么看。规则引擎最大的优势是——确定性。你写一条规则，它就一定按这个逻辑走，不会抽风。

我常用的规则分四类：

规则类型	检测目标	示例
长度规则	最短/最长长度	len(pwd) < 8 → 拒绝
字符集规则	必须包含的字符类型	大写 + 小写 + 数字 + 特殊字符
黑名单规则	常见弱口令、公司名、年份	"password", "123456", "company2024"
模式规则	键盘序列、重复字符、递增序列	"qwerty", "aaaa", "1234"

这里有个坑，我踩过。黑名单不能只做精确匹配。用户会把「password」改成「p@ssword」或者「passw0rd」。所以规则引擎里必须内置一个模糊匹配层。

4.4 机器学习模型：选对算法比调参重要

模型部分，我建议别一上来就上深度学习。口令检测这个场景，数据量通常不大，特征维度也不高。用轻量级的分类器就够了。

我个人最常用的是 XGBoost 和 LightGBM。原因有三：

• 可解释性好：能输出每个特征的重要性，方便跟审计解释
• 训练快：几万条样本，几秒钟就训练完了
• 不容易过拟合：树模型对特征工程的要求没那么苛刻

特征怎么提？我一般用这五类：

1. 统计特征：长度、大写字母数、数字数、特殊字符数
2. 熵值特征：信息熵、字符分布均匀度
3. 模式特征：最长重复子串长度、键盘序列长度、递增序列长度
4. 字典特征：口令中包含的常见单词数、常见替换数
5. 规则评分：把规则引擎的软评分直接作为特征喂给模型

代码实现大概长这样：

import xgboost as xgb
from sklearn.model_selection import train_test_split

# 特征矩阵：每行是一个口令的特征向量
# [长度, 大写比例, 数字比例, 熵值, 重复长度, 规则评分]
X = [[12, 0.25, 0.33, 3.2, 2, 65],
     [8,  0.0,  0.5,  2.1, 4, 30],
     [16, 0.19, 0.25, 3.8, 1, 85]]

# 标签：1=弱口令，0=强口令
y = [0, 1, 0]

model = xgb.XGBClassifier(
    n_estimators=100,
    max_depth=4,
    learning_rate=0.1,
    eval_metric='logloss'
)

model.fit(X_train, y_train)

# 推理时，模型输出风险概率
prob = model.predict_proba([new_password_features])[0][1]

4.5 混合决策：谁说了算？

规则和模型都跑完了，怎么融合？我见过两种做法：

融合策略	做法	适用场景
规则优先	规则命中直接拒绝，模型结果仅做参考	合规要求严格的行业（金融、政务）
加权融合	规则评分 + 模型概率 = 综合分数	需要平衡安全性和用户体验的场景

我自己的项目里，用的是「规则优先 + 模型兜底」的策略。具体来说：

• 第一阶段规则命中 → 直接拒绝，不给模型机会
• 第一阶段规则通过 → 进入模型判断
• 模型判断为弱口令 → 拒绝，并附上模型给出的风险原因

这样做的好处是，合规审计的时候，你可以说「我们严格按照 NIST 标准执行了长度和字符集检查」。而模型部分，你可以说「作为额外安全层，用于检测规则无法覆盖的弱口令模式」。

4.6 避坑指南：我踩过的三个坑

做混合引擎这几年，我踩过不少坑。挑三个最典型的说说：

坑一：规则和模型打架

有一次，规则引擎给一个口令打了 70 分（挺高的），但模型判成了弱口令。查了半天才发现，规则引擎没检测到「admin2024」里的「admin」——因为黑名单里只写了「administrator」。模型却从特征里发现了这个模式。

解决方案：把模型判弱的口令定期回灌到规则引擎的黑名单里。让规则越来越聪明。

坑二：模型过拟合到规则评分

我曾经把规则评分直接当特征喂给模型。结果模型学歪了——它发现规则评分高的基本都是强口令，于是干脆只看规则评分，其他特征都不用了。这等于模型退化成了规则的复读机。

解决方案：规则评分只作为辅助特征，权重不要太高。或者在训练时做特征随机丢弃。

坑三：线上推理延迟太高

模型推理虽然快，但特征提取这一步可能很慢。尤其是字典匹配，如果字典有几十万条，每次都要遍历一遍，延迟直接飙到几百毫秒。

解决方案：用 Trie 树或者 Aho-Corasick 自动机做字典匹配。匹配时间从 O(n) 降到 O(m)，m 是口令长度，跟字典大小无关。

4.7 落地效果：数据说话

最后给组数据吧。我在某互联网客户那边部署这套混合引擎之后，效果是这样的：

指标	纯规则引擎	混合引擎
弱口令检出率	72%	94%
误拒率	3.1%	1.8%
平均检测延迟	0.3ms	2.1ms
合规审计通过率	85%	100%

延迟从 0.3ms 涨到 2.1ms，但换来的是检出率从 72% 提到 94%。这个 trade-off，我觉得值。

嗯，混合引擎的核心就这些。说白了，规则和模型不是二选一，而是搭档。规则负责「守门」，模型负责「巡逻」。两者配合好了，才能既过合规，又防住真正的风险。