4.4 数据库与密码强度审计

4.4 数据库与密码强度审计

本节摘要：数据库暴露面检查与口令强度审计是一对孪生工作——前者确认"数据库服务是否只对该听的人开口"，后者回答"一旦口令文件外泄，其中的凭据能撑多久"。本节讲数据库评估的检查维度、哈希口令的离线强度审计方法（在自有导出数据上做），以及把结论写成整改建议的完整路径。

这一节在功能域矩阵里是"凭据强度结论"的产地。它承接 4.3 的应用层视角下探到数据层，同时为第六章的加固建议提供最直接的依据——口令策略整改是安全整改里性价比最高的一项。

一、先划清这个域的两种工作

工作一：数据库暴露面检查。 对象是数据库服务本身：监听地址是全接口还是仅本机、默认账户是否启用、认证方式是否允许弱协商、传输是否加密、权限分配是否遵循最小化。这类检查大多是"配置核对"性质——用 4.1 的服务识别确认端口与版本，再登录数据库侧核对配置项。它的产出是一份偏差清单，直接对应 1.3 节讲的审计角色工作。

工作二：口令强度审计。 对象是口令的存储形态。现代系统不存明文口令，存的是哈希值；强度审计回答的问题是：这些哈希值如果整体泄露，攻击者离线爆破需要多少代价。这项工作在授权测试里只对自有或授权数据做——通常来自两种合法来源：授权范围内系统导出的口令文件副本、组织自己发起的合规审计样本。

两种工作合并成一条逻辑链：暴露面决定"哈希库有没有可能被拿走"，强度审计决定"拿走之后撑多久"。两个环节都要过硬，缺一即溃。

二、数据库暴露面的五个检查维度

以靶机上的数据库服务为例，五个维度的核对方式如下表。注意其中大半可以在不尝试任何凭据的情况下完成——这再次体现了"验证存在性而非破坏性"的原则。

# 暴露面核对的服务识别部分（靶机上）
nmap -sV -p 3306,5432,1433 192.168.56.102
# 输出片段：
# 3306/tcp open  mysql  MySQL 5.x
# 版本与端口的暴露本身就是"监听范围"维度的事实来源

# 传输形态确认：4.6 节的抓包工具看会话是否明文
sudo tcpdump -i eth0 -A host 192.168.56.102 and port 3306 -c 20
​

三、口令强度审计：在自有数据上做离线评估

离线强度审计的工具链（哈希破解类工具）在 Kali 里配置齐全，但本节的用法立场先讲明白：对象是自有导出的口令样本，目的是评估策略强度，产出是整改建议——不是教怎么破别人的账号。以下演示都在实验数据上进行。

第一步：识别哈希形态。 不同系统用不同的哈希方案，形态决定审计参数。哈希前缀与分隔符是判断依据，例如以特定标识开头的格式对应自适应哈希方案（自带慢化因子，设计目标就是提高离线爆破成本）。

第二步：跑基准。 审计工具都有基准模式，先测自己硬件的吞吐能力，这一步不涉及任何真实口令——它只告诉你"这块显卡每秒能尝试多少次"。

第三步：用样本字典做评估。 取一份组织常见的弱口令模式生成的字典（公司名加年份、键盘序列、常见词表），对自有样本跑一遍，统计命中率。

# 基准模式：测硬件吞吐，不碰任何真实口令
hashcat -b
# 输出片段：
# Hashmode: 3200 (bcrypt)
# Speed.#1.........:      1234 H/s  ← 慢哈希的吞吐量级

# 对自有样本的评估（示例使用实验生成的样本文件）
# 命中率 = 命中条数 / 样本总数，这个比值就是"策略强度"的量化指标
john --wordlist=org-patterns.txt lab-sample.hash
# 输出片段：
# guessed123        (user07)
# ...逐条输出命中结果，统计后写进审计底稿
​

读结果的姿势：命中率才是结论，爆破速度只是背景。一次评估跑出 8% 的命中率，含义是"组织内每十二个口令里有一个能被常见模式字典猜中"——整改建议由此直接产生：口令策略加长度与复杂度要求、接入泄露口令库校验、关键系统上多因素认证。

慢哈希与快哈希的对比是必讲的知识点：快哈希（如无盐的旧消息摘要类）吞吐高出慢哈希几个数量级，同样的口令在快哈希面前存活时间以分钟计。这就是"认证策略"维度里"强制强哈希"的整改依据——存储方案的换代，能让整库口令的离线爆破成本翻上万倍。

四、把结论写成整改建议

强度审计的产出最终要落到可执行的整改。一份合格的条目包含五要素，拿命中率场景举例：

• 发现描述：对授权样本的离线评估中，常见模式字典命中率为 8%；
• 判定证据：样本规模、字典构成、命中统计与耗时，原始输出归档；
• 影响分析：一旦口令库外泄，相当比例账户可在短窗口内被还原，横向风险高；
• 整改建议：口令策略（长度优先于复杂度）、泄露库校验、关键系统多因素、存储方案换慢哈希；
• 复测方式：整改后重新抽样评估，命中率应降到约定阈值以下。

⚠️ 纪律重申：口令样本是测试中最敏感的数据类别。样本只在授权与约定范围内存在，评估结束按 1.2 节的数据处理条款销毁并留痕；报告里只出现统计结论，绝不出现任何具体口令。

强度审计问答：三个实施疑问

问：审计样本从哪里来才合规？ 两条合法通道：授权范围内的系统在合同允许下导出的口令文件副本；组织自己发起的合规审计所采集的样本。两者都要走数据条款（1.2 的第四要素）——脱敏、限人、限期限、到期销毁。任何"顺手多留一份"都直接违反红线三。

问：命中率多高算需要整改？ 没有绝对阈值，参考锚点是行业基线与自身历史：首次审计常见个位数百分比（常见模式字典的命中），整改后应显著下降。更重要的指标是命中结构——命中的若是管理员账户或服务账户，整改优先级要高于普通用户账户，因为它们的失守半径大得多。

问：跑一次审计要多久，会不会影响生产？ 离线审计只碰样本文件与算力，不触碰生产系统，时长取决于样本规模、哈希方案与硬件——这正是先跑基准（第二步）的意义：基准数字乘以样本量，时长就是可预期的。快哈希样本分钟级，慢哈希样本小时级，预算据此排。

从审计到策略：整改建议的层次

把整改建议从"改口令"展开成有层次的方案，是本节产出质量的关键。三个层次按成本递增：第一层，策略收紧——长度下限提高、常用模式禁用、泄露库校验接入，成本最低、见效最快；第二层，存储换代——旧哈希方案迁移到自适应慢哈希，一次性工程量中等，收益是把整库的离线爆破成本抬高几个数量级；第三层，架构减压——关键系统上多因素认证，把"口令单点"降级为"口令加持有物"，根治口令被还原后的风险传导。

写报告时三层并列给出，让客户按预算选择组合——这比单写"加强口令管理"的空话有用得多。多数组织的合理路径是先做第一层止血，再排期第二层，对核心资产直接上第三层。分层的本质是承认预算约束的存在，一份不承认约束的建议书永远不会被执行。

这个功能域收尾后，第四章还剩两个域：无线安全与流量逆向。下一节先看无线——那是唯一必须依赖物理射频的功能域，也因此有最独特的守界要求。