网站弱口令风险排查与强制安全策略设置

弱口令问题从来不是一个技术难题，而是一个管理惯性问题。每次安全事件通报里，通过弱口令、默认口令、撞库攻击进入系统的案例占比常年居高不下。很多运维团队把精力放在WAF、IDS、态势感知这些高阶设备上，却忽略了最基础的认证入口。攻击者根本不需要0day漏洞，只要用admin/admin123或者root/toor就能直接拿到系统最高权限。更麻烦的是，很多业务系统在开发阶段为了方便调试，设置了简单口令，上线后没人记得去改，这些“后门”一留就是几年。

弱口令不是只有123456和password这么简单。根据实战攻防演练中的数据，攻击者常用的字典早已进化到高度定制化阶段。典型的弱口令包括几类：系统默认口令，比如tomcat/tomcat、weblogic/weblogic1、mysql的root空口令；键盘序列口令，比如1qaz2wsx、qwerasdf这种看似随机实则规律的组合；企业信息相关口令，比如公司缩写加年份、部门名称加数字；还有一类是看似复杂但实际被泄露过的口令，攻击者手里有几十亿条泄露库，你的复杂口令如果跟其他平台相同，等同于裸奔。真正需要排查的，是那些满足复杂度要求但实际强度为零的口令。

排查工作要分层次进行，不能拿着一份字典就盲目扫描。第一层是资产梳理，把所有对外和对内的Web登录入口、SSH端口、数据库端口、FTP服务、远程桌面全部列出来。很多团队以为自己清楚资产边界，实际一查就会发现测试服务器、临时搭建的Demo环境、已经下线的旧系统还开着端口。第二层是账户审计，每个系统里有多少活跃账户、多少僵尸账户、多少测试账户，这些账户的权限分布如何。测试账户往往是弱口令的重灾区，开发人员随手建个test/test账号，权限还经常给到管理员级别。第三层才是口令强度检测，用定制化字典做登录尝试，字典里必须包含企业名称、产品名称、员工姓名拼音、常见年份数字等本地化信息。

实际操作中，口令强度检测需要注意频率控制和账户锁定机制的规避。很多生产系统设置了连续失败锁定策略，直接暴力扫描会导致大面积账户锁定，影响业务。正确的做法是先拉取账户列表，对每个账户只尝试3到5个最可能的口令，命中率反而更高。另外，不要只盯着登录界面，很多系统的密码重置接口、API接口同样存在弱口令问题，有些接口甚至没有失败次数限制，这才是真正的高危点。

排查不能只停留在应用层，代码审计同样关键。很多系统把口令硬编码在配置文件或源码里，这种情况比用户弱口令更致命。下面这段代码就是典型反面案例，数据库连接密码直接写在配置文件中且使用弱口令：

# 危险示例：硬编码弱口令
spring.datasource.url=jdbc:mysql://192.168.1.100:3306/production
spring.datasource.username=root
spring.datasource.password=root123

正确的做法是使用环境变量或密钥管理服务，同时确保口令强度达标。更隐蔽的问题出现在口令重置逻辑中，有些系统生成的重置令牌是6位纯数字且未设置有效期，攻击者可以在短时间内遍历所有可能。还有的系统在日志中明文记录了用户登录口令，这些日志如果被攻击者获取，所有账户直接沦陷。代码层面必须检查的点包括：口令存储是否使用了安全的哈希算法、是否加了盐值、重置令牌是否具备足够的随机性和时效性、日志是否脱敏处理。

口令策略设置不是简单地把最小长度改成8位、要求包含大小写和特殊字符就完事了。NIST最新的SP 800-63B标准已经明确推翻了传统认知，不再强制要求定期更换口令和复杂组合，因为研究表明这些要求反而导致用户使用可预测的模式。真正有效的强制策略应该包含以下维度：最小长度至少12位，这是目前算力条件下暴力破解的安全阈值；禁止使用已知泄露口令，在用户设置或修改口令时对接泄露库进行实时校验；实施基于风险的自适应认证，当检测到异地登录、新设备登录、异常时间登录时触发二次验证；账户锁定策略要设置合理的阈值和锁定时长，通常建议连续5次失败锁定15分钟，同时配合IP级别的速率限制。

多因素认证是当前对抗弱口令最有效的手段，没有之一。即使口令被泄露，攻击者没有第二因素也无法登录。实施时需要注意，短信验证码不应作为唯一的第二因素，SIM卡克隆和短信拦截攻击已经非常成熟。优先推荐TOTP应用或硬件安全密钥，对于不支持的旧系统，至少要在网络层面加一层堡垒机或VPN网关，确保口令不直接暴露在互联网上。

互联网暴露面的系统与内网系统的策略应该完全不同。对外系统必须强制启用多因素认证，口令最小长度不低于16位，并且要部署登录行为分析，对异常登录实时告警。内网系统虽然相对安全，但横向移动攻击恰恰利用的就是内网弱口令，所以内网同样不能放松。数据库账户要区分业务账户和管理账户，业务账户遵循最小权限原则，管理账户的口令必须定期轮换且每次使用后立即变更。对于无法修改口令的老旧系统，比如某些工控设备、遗留系统，至少要在网络层面做隔离，用跳板机代理访问，跳板机本身强制强口令和多因素认证。

API和机器账户的口令管理经常被忽略。这些账户通常不归个人所有，而是属于某个服务或脚本，口令往往长期不变且多人知晓。正确的做法是使用密钥管理服务自动轮换，或者至少把这些口令存在密码保险箱中，每次使用前临时获取，使用后立即失效。服务账户的口令长度应该比人工账户更长，建议32位以上随机字符串，因为不存在记忆成本。

Linux系统层面，PAM模块是实施口令策略的核心。通过配置pam_pwquality.so可以强制口令复杂度，但更推荐使用pam_pwhistory.so禁止重复使用历史口令，以及pam_faillock.so实现账户锁定。以下是一个生产环境的PAM配置示例，兼顾了安全性和可用性：

# /etc/pam.d/system-auth 关键配置
auth        required      pam_faillock.so preauth silent audit deny=5 unlock_time=900
auth        required      pam_faillock.so authfail audit deny=5 unlock_time=900
account     required      pam_faillock.so
password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 minlen=12 difok=4
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok remember=10

Windows环境通过组策略统一管控，在“计算机配置-安全设置-账户策略-密码策略”中设置最小长度、复杂度要求和历史记录，同时在“账户锁定策略”中配置锁定阈值。域环境建议配合Fine-Grained Password Policy对不同OU设置差异化策略，比如管理员账户要求16位以上，普通用户12位即可。对于Web应用，在应用层实现口令策略是最灵活的方案，可以在注册和修改口令的接口中集成zxcvbn这类口令强度评估库，实时反馈口令强度，同时对撞库攻击实施验证码和频率限制。

一次性排查解决不了根本问题，因为新系统会不断上线、新账户会不断创建、口令会不断被修改。必须建立长效机制，至少包括以下措施：定期自动化扫描，每周对所有资产做一次弱口令检测，结果自动推送到运维工单系统；口令变更审计，所有口令修改操作都要记录日志并触发告警，防止攻击者修改口令后长期潜伏；泄露监控，订阅外部威胁情报，当企业域名相关的泄露数据出现时第一时间强制相关账户口令重置；安全意识培训不是走过场，要让每个员工理解为什么12位以上的口令比8位复杂口令更安全，为什么不要在多个平台使用相同口令。

很多团队担心强制策略会影响用户体验，这个顾虑可以通过技术手段解决。单点登录减少口令输入频率，生物识别替代口令输入，无口令认证方案如Passkey正在成为趋势。但在这些技术完全普及之前，口令仍然是绝大多数系统的第一道防线。把这道防线从纸糊的换成钢板，投入的成本远低于事后应急响应的代价。现在就可以做的事情是：打开你的服务器，检查一下root账户的口令强度，看看有没有超过12位，有没有包含企业名称或常见单词，有没有在其他地方重复使用。这个动作只需要五分钟，但可能是你今天做的最有价值的安全工作。