弱口令风险是什么
弱口令指容易被猜中或被字典命中的口令：长度过短、纯数字、常见词组合、厂商默认口令，以及同一口令在多个系统复用。它的危害不限于单点失陷——一旦某个入口被攻破，攻击者通常会用同一套口令去尝试其他系统，形成横向移动。治理的关键在于覆盖全部登录入口而不只是新系统，并把「口令强度」与「认证方式」一起考虑：能上多因素认证和密钥认证的场景，收益远大于单纯加长口令。
基本信息
| 高发位置 | 服务器与设备管理入口、数据库、中间件控制台、堡垒机、VPN |
|---|---|
| 主要成因 | 厂商默认口令未改、上线图省事用简单口令、长期不轮换、跨系统复用 |
| 危害 | 单点失陷后横向移动，可快速扩大为多系统失守 |
| 治理要素 | 入口盘点、强度策略、默认口令清零、泄露口令比对、认证方式升级 |
| 检测手段 | 登录失败日志、口令强度审计、离线比对泄露口令库 |
| 优先动作 | 先清理默认口令与特权账号，再推进多因素认证 |
典型场景
- 新设备与新服务上线时保留初始口令，后续无人修改
- 运维图方便把口令设为固定规则，如厂商名加年份
- 同一口令在办公、服务器与云平台复用，一处泄露全线告急
- 共享账号多人使用，口令长期不轮换且无法定位操作者
- 服务账号口令写在配置文件或脚本里，明文存放
- 测试环境用简单口令，事后直接连配置一起复制到生产
治理动作清单
治理动作清单
1. 盘点所有登录入口：系统、数据库、中间件、设备管理口、堡垒机
2. 强制口令复杂度与长度（重要系统建议 >=12 位或口令短语）
3. 禁止默认口令上线：新设备/新服务上线检查表加一项
4. 定期比对泄露口令库（企业可用 HIBP 类接口或离线库）
5. 关键系统启用多因素认证
6. 特权账号单独管理，禁止与普通账号共用口令
7. 服务账号口令集中托管，避免写在配置与脚本里
# 落地要点：把口令要求写进上线检查表，否则每次都靠人记得服务器侧自查示例
服务器侧自查示例
# 检查是否存在空口令账户（需 root）
awk -F: '($2=="") {print $1}' /etc/shadow
# 检查 sudo 免密配置
sudo grep -r NOPASSWD /etc/sudoers /etc/sudoers.d/ 2>/dev/null
# 检查近期失败登录排名，定位被持续尝试的账号
sudo grep 'Failed password' /var/log/secure | awk '{print $(NF-5)}' | sort | uniq -c | sort -rn | head口令策略建议
| 账号类型 | 长度与复杂度 | 附加控制 |
|---|---|---|
| 普通用户 | 至少 12 位或口令短语 | 禁止与历史口令重复，启用登录异常告警 |
| 特权账号 | 至少 16 位随机 | 独立账号、多因素认证、操作审计 |
| 服务账号 | 长随机口令 | 集中托管、按需下发、不进代码仓库 |
| 设备默认账号 | 首次登录强制修改 | 禁用或改名默认账号，关闭远程默认维护 |
同一口令在多系统复用会把单点失陷放大为全网失陷；口令管理器与分级口令策略是有效手段，比反复要求用户自己记更可靠。
口令审计本身要合规：离线比对泄露口令库时不要收集明文口令，也不要在生产环境批量尝试登录，避免触发账号锁定或造成业务影响。