1. 从一次内网巡检说起弱口令就是这么混进来的前阵子帮一家企业做内网安全现状摸底整体架构还算规范防火墙、杀毒、堡垒机都上了按理说防护水平不算差。结果我在核心业务服务器的运维账号字典表里做了一次常规碰撞测试大概十分钟不到就把一台测试环境、一台正式数据库的账号口令试了出来——不是用了什么高级0day就是最普通的弱口令。那台正式数据库的账号就是sa口令是sa123456。这种组合在攻击者的字典文件里几乎是标配。更让我意外的是问题不在某个新人身上而是这台数据库是三年前一位已经离职的DBA配的中间经历了多次人员交接没人动过这个口令。安全制度写了禁止使用弱口令但落地的时候没有检查机制制度就是一纸空文。这是我做安全相关工作以来最深的体会弱口令从来不是有没有安全意识的问题而是有没有检查机制的问题。只要缺少一个自动化的发现手段再强的安全意识也会在人员流动和业务压力面前被稀释。这篇文章围绕弱口令这个老生常谈的话题把定义、原理、破解逻辑、危害以及防护方案完整梳理一遍。适合三类人看一是刚入行的安全工程师需要理解口令攻击的基本链路二是运维/DBA/开发想知道自己维护的系统为什么总被盯上三是普通用户想搞清楚自己的账号在攻击者眼里到底值多少钱。全程不堆砌术语尽量用大白话把原理讲透。2. 弱口令不是只有123456识别边界与判断标准2.1 弱口令的明确定义一切能被猜出来的口令很多人的理解里弱口令就是123456、admin、password这种一眼假的组合。这个理解没错但远远不够。从攻击者的视角看弱口令的本质是可预测性。一个口令能不能被猜中取决于它是否存在于攻击者的候选清单里。这个清单可以是公开泄露的口令库、常见键盘轨迹、各种变体规则也可以是针对目标个人信息定制的社工字典。所以判断标准只有一个如果这个口令能够通过自动化工具在可接受的时间内被猜中那它就是弱口令无论它看起来多复杂。举个例子Pssw0rd看起来符合复杂口令的标准——有大写、有小写、有特殊符号、有数字——但它出现在几乎所有主流字典文件的前100条里。攻击者根本不用暴力遍历直接在字典里一查就命中了。这就是典型的看起来很强实际上弱得不行。2.2 弱口令的常见类型不只是短口令我习惯把弱口令分成五个大类这样排查的时候思路比较清晰第一类默认口令和初始口令。设备出厂自带的admin/admin应用初始化时的root/root打印机、摄像头、路由器后台的默认账号。很多设备管理员压根没改过默认口令这类最容易被批量扫描工具直接拿下。第二类纯数字短口令。123456、888888、666666、5201314这类。特点是用键盘敲起来很顺记忆成本极低。对于暴力破解工具来说6位纯数字只有100万种组合现代CPU毫秒级就能跑完。第三类与个人信息强相关的口令。姓名拼音生日、手机号后六位、工号、公司名称缩写、车牌号、伴侣或孩子的名字。这一类在定向攻击里极其致命因为攻击者只要花十几分钟翻一下你的社交媒体就能构建出一个很精准的字典。第四类键盘路径型口令。qwerty、1qaz2wsx、zxcvbnm这些是沿着键盘轨迹敲出来的输入速度快但完全在字典覆盖范围内。第五类带规律变体的口令。在基础口令上加个数字或符号比如password1、admin123!、a1234567。这类衍生规则是字典攻击里的标准策略攻击者会拿基础词去套各种常见后缀。2.3 识别口令强度的常见误区我在安全培训和项目交流中经常听到这些说法我的口令有十位够复杂了。——如果这十位是wangwei1985那跟没有口令没区别。我把生日放在中间别人猜不到的。——生日恰恰是最容易被想到的特征之一。我定期换口令三个月换一次。——如果新口令只是把abc123改成abc124那换不换没有本质区别。这些误区的共性是把复杂度等同于安全强度而实际上安全强度取决于猜测难度与泄露风险的综合评估。口令再复杂一旦出现在泄露库里或者被撞库成功安全性就归零了。3. 攻方视角下的破解逻辑为什么字典总能撞开大门讲防护之前必须先站在攻击者角度理解破解思路。这里不涉及具体攻击工具的教程只讲逻辑和原理目的是帮助大家建立正确的防御认知。3.1 撞库被忽略的隐形威胁撞库的逻辑很简单收集互联网上已泄露的账号密码组合用自动化脚本在目标系统里批量尝试登录。很多人觉得自己口令设得还行不至于被暴力破解却忽略了你用的可能是跟其他网站完全相同的口令。举个例子你在某个小型论坛注册了一个账号用了zhang123这个口令。后来这个论坛数据库泄露了攻击者拿到了明文或哈希口令。接下来攻击者会拿这批账号口令去尝试主流邮箱、网盘、企业系统、云平台。只要你在这些地方用了同一个口令账号就等于拱手相让。撞库之所以难防是因为它绕过了口令复杂度的限制——你的口令可能非常复杂但它已经泄露了复杂没有意义。这也是我在安全培训中反复强调的一点对个人而言最危险的不是弱口令而是口令复用。3.2 字典攻击为什么字典比暴力破解更高效暴力破解是穷举所有可能的字符组合但纯暴力在现实攻击中效率其实很低。一个8位大小写字母数字符号的口令空间大约有6万亿种组合就算每秒能跑10亿次也要好几个小时到几天。当然这个时间在GPU集群面前会大幅缩短但攻击者通常有更省力的选择——字典。字典文件是长期积累的人类口令行为统计库。它包含了历史上各种数据泄露事件中真实出现的口令再经过变体规则扩充。好的字典覆盖了绝大多数普通用户的思维习惯。用一句白话总结暴力破解和字典攻击的区别暴力是把整个图书馆的书翻一遍找那句台词字典是直接翻剧本里出现频率最高的那页。3.3 破解速度算力增长带来的质变提到破解速度我从实际测试数据来聊。在我做过的一次自检中一台普通配置的机器针对某个系统的口令哈希做离线破解一个6位的纯数字口令基本是秒出。8位的小写字母字母数字组合在GPU加速下也就是几分钟到几十分钟的量级。如果我用了预计算表彩虹表来加速很多常见口令连计算都可以省掉直接查表出结果。这背后是算力迭代带来的变化。口令破解非常契合GPU的并行计算架构可以同时跑海量的候选口令。云算力又让普通人也能按小时租到足够强的设备。所以我的口令够复杂破解不出来这个想法在离线攻击场景下已经越来越站不住脚了。另一个容易被忽略的向量是在线暴力破解。很多系统的登录接口没有做速率限制攻击者可以不停尝试。我见过不少业务后台管理系统的登录接口完全没有锁定机制也没有验证码。攻击者拿字典慢慢跑一晚上试几万次总有一次能碰上。这里必须强调的是讲解这些原理不是为了教人怎么攻击而是要让大家理解一个看起来还能用的口令在攻击者手里可能撑不过一顿饭的时间。3.4 人为因素社会工程学与弱口令的组合拳技术手段之外攻击者还会充分利用人为因素。比如通过公开信息收集目标单位内部员工的姓名、工号、手机号然后生成针对性的社工字典。这种字典命中率远高于通用字典因为企业内部系统常见的口令习惯就是姓名拼音工号英文名出生年月。还有一种场景攻击者通过钓鱼邮件在目标电脑上种植键盘记录程序直接记录用户敲击的明文口令。这种情况下再强的口令策略也没有意义因为问题已经超出了口令本身。弱口令治理不能只看口令策略还要跟整体安全意识培训挂钩。4. 弱口令被攻破后的放大效应从一台设备到一片网络4.1 服务器失守后的内网横移弱口令的可怕之处不在于它本身能被猜中而在于猜中之后带来的连锁反应。我在一次攻防演练中遇到过这样的情况某单位一台边缘业务系统的后台用了弱口令攻击者登录后发现这台机器上有内网其他主机的连接记录和凭据缓存。凭借这台边缘设备做跳板攻击者最终进入了核心业务网段。整个过程没有利用任何系统漏洞完全就是沿着合法路径一路走过去的。这就是所谓的横移。在攻防对抗中一台沦陷的设备足够成为攻击者在内网继续渗透的支点。如果这台设备权限够高还能抓取内存中的其他账号明文口令形成放大效应。4.2 物联网设备与弱口令的天然配对IoT设备是弱口令的重灾区。摄像头、路由器、打印机、门禁控制器、NAS这些设备通常没有键盘输入条件出厂默认口令往往非常简单用户也很少会主动修改。大量摄像头被批量扫描工具发现之后直接被拉入僵尸网络用于发起DDoS攻击。这些都是真实发生过的安全事件。IoT设备与弱口令的组合相当于把家门钥匙挂在了锁孔旁边。4.3 口令复用带来的连带灾难关于口令复用我在一次安全咨询服务中遇到过一个典型场景一家企业的一位核心员工在内部系统、个人邮箱、外部协作平台、云服务控制台都使用了相同的口令。攻击者先通过某次第三方数据泄露拿到了他在某个小众网站上的口令然后逐一尝试最终连进了云服务控制台。更关键的是他还有管理员权限可以通过控制台直接批量读取云资源、导出数据。整个过程的成本极低——攻击者可能只花了两个小时就把一个人多年的数字资产全部拿下。5. 落地防护企业侧和个人侧的系统性治理方案5.1 企业侧让弱口令无处藏身企业治理弱口令不能只靠禁止使用弱口令这句话必须有可落地的技术手段和流程约束。第一道防线口令策略的技术基线。这里不是一个简单的最小长度复杂度就能解决的。我建议的基线是关键系统强制口令长度不低于12位且支持使用较长短语普通业务系统不低于8位强制包含至少三类字符所有系统中的默认口令必须首次登录强制修改。口令策略不能只做长度要求因为password123同样满足复杂度却不安全。第二道防线登录侧的攻击缓解。所有面向互联网的系统登录接口必须启用验证码或二次校验连续失败5次锁定账号15分钟以上支持MFA多因子认证的系统一律要求管理员开启。成本不高但能有效拖慢在线猜测的速度。第三道防线主动的弱口令扫描。这里说的扫描是自检性质的安全团队定期对内部系统做口令脆弱性核验把弱口令当作漏洞来管理。扫描工具的选择方面开源的离线检测工具和商业安全评估产品都有不少选择关键是建立检测-通知-整改-复测的闭环流程。只有定期扫描才能发现那些历史遗留的弱口令。第四道防线与账号生命周期管理联动。员工离职后账号必须立刻冻结或注销外包人员权限要设定有效期共享账号尽可能杜绝如果不得不共用配合密码保险箱类工具管理访问入口。我在多个项目中的经验是弱口令整改中最阻力最大的往往是业务部门。他们会认为新的口令策略影响工作效率、耽误事。解决方式不是强硬推而是做好两类工作第一把弱口令风险具象化拿行业内真实案例做宣讲第二提供体验友好的密码管理器。与其让员工记住复杂的随机口令不如让工具来管。5.2 个人侧几个简单但足够有效的习惯对个人用户来说不需要掌握很复杂的安全知识做到下面几条就能覆盖90%的风险口令不重复核心账号邮箱、支付、云服务、社交主账号每个单独使用不同口令普通论坛类账号可以分组共享但绝不能与核心账号重复。使用口令管理器把口令交给专业的密码管理器生成和保存自己只需要记住一个主口令。主口令可以用一句只有自己知道的话加上特殊字符转换比如一句歌词、一句古诗变体。开启两步验证重要账号一律开启两步验证。攻击者即使拿到口令也过不了手机这一关。就算哪天口令泄露了也不至于立刻被登录。定期自查泄露情况利用一些公开的泄露查询服务查看自己的邮箱或手机号是否出现在历史泄露数据中。如果出现在某次泄露里且你还在其他平台用过相同口令立刻去改。5.3 口令强度自查教大家一个简单的评估方法我经常被人问你看我这个口令行不行我的判断思路是这样的第一先去主流泄露库里查一下这个口令是否出现过历史泄露第二看口令长度是否达到12位以上第三看结构是否包含无规律的字母/数字/符号组合而不是一个单词加一串数字第四看是否包含个人信息特征第五看是否与其他账号复用。以上五条任何一条不过建议就要调整。我自己用的口令大多是密码管理器生成的随机串比如kF7#mL2$qR9vT4这种长度16位以上全程不重复。虽然这种口令不好记但根本不需要记住——工具帮我们解决记忆问题。6. 我这几年在口令治理上踩过的坑和攒下的经验6.1 口令策略设得越严效果不一定越好最开始做安全体系建设的时候我一度把口令策略设得非常严格15位以上、必须包含大小写数字特殊符号、90天强制更换、不允许与历史10次口令重复。结果怎么样员工在一个便签纸上写满了口令贴在显示器旁边。这个结果讽刺但真实——口令策略太严反而逼着用户把口令明文写出来安全水平反而下降了。后来NIST更新口令安全指引时也建议不再强制用户频繁更换口令而是把重点放在口令长度和泄露检测上。现在的做法是口令长度优先复杂度适当要求登录侧配合MFA通过泄露库检测阻止已知泄露口令的使用。这个组合在防弱口令和可用性之间找到了平衡。6.2 不同系统要做口令策略分级不要对所有系统一视同仁。核心业务系统、云平台控制台、数据库这些一旦被攻破就是重大事故口令策略必须最严格强制启用MFA。普通内部管理系统策略可以适当放宽保证效率。对外展示性系统、临时环境口令要求高但可以配合更便捷的登录方式比如SSO单点登录。分级治理还有一个好处安全资源有限不可能所有系统都投入同样的检查力度分级能让你把精力集中在最关键的资产上。6.3 弱口令自检的频率与节奏边界暴露在公网的系统和内部系统自检频率要分开。公网系统建议每个月做一次内部系统建议一个季度一次临时上线或对外演示的系统上线前必须做一次。自检结果要跟工单系统打通发现问题直接派单给负责人限期整改。整改完成后再做复测确认整改有效。有个细节很多人容易忽略扫描出来的弱口令数据本身就是敏感信息。这类报告要严格控制知悉范围防止泄露后反过来被攻击者利用。我在处理这类报告时会脱敏、加密、设置访问权限。6.4 最后分享一个小技巧口令安全评估从长度入手很多朋友总喜欢纠结于口令里要不要加个感叹号、数字放在前面还是后面。根据我的经验这些细节的边际收益已经很低了。对于口令强度提升最明显、最有效的动作是拉长口令长度。密码熵值这个说法大家可能听过简单理解就是猜测口令需要尝试的次数。每增加一位长度猜测空间就扩大一个数量级。把口令从8位拉到14位哪怕只用小写字母加数字猜测难度也已经远超一个8位的高复杂度口令。我个人在检查员工口令时有一个比较简单的判断标准低于12位直接判弱12到15位看有没有明显规律16位以上即便是纯小写字母加数字也已经具备不错的基础防护力。当然前提是不能用公开的常见短语拼接。这条经验对普通用户也适用与其强迫自己记Ab2024#Zh这种难记的口令不如用一句只有自己知道的长句子的首字母组合比如去年夏天我在青岛海边捡到一枚蓝色贝壳转成qxztwzqdhbjyymlsk长度够、好记、不重复口令强度也够。再配合两步验证基本可以应对绝大多数攻击场景。弱口令治理不是一锤子买卖而是一个持续运转的过程。系统在变、人员在变、业务在变口令的安全状态随时可能退化。真正有效的办法是把检查和处理流程固化到日常运维节奏里让它成为一项例行工作而不是等出了事才想起来排查。这一点是我这些年做安全最想跟大家分享的体会。
1. 从一次内网巡检说起弱口令就是这么混进来的前阵子帮一家企业做内网安全现状摸底整体架构还算规范防火墙、杀毒、堡垒机都上了按理说防护水平不算差。结果我在核心业务服务器的运维账号字典表里做了一次常规碰撞测试大概十分钟不到就把一台测试环境、一台正式数据库的账号口令试了出来——不是用了什么高级0day就是最普通的弱口令。那台正式数据库的账号就是sa口令是sa123456。这种组合在攻击者的字典文件里几乎是标配。更让我意外的是问题不在某个新人身上而是这台数据库是三年前一位已经离职的DBA配的中间经历了多次人员交接没人动过这个口令。安全制度写了禁止使用弱口令但落地的时候没有检查机制制度就是一纸空文。这是我做安全相关工作以来最深的体会弱口令从来不是有没有安全意识的问题而是有没有检查机制的问题。只要缺少一个自动化的发现手段再强的安全意识也会在人员流动和业务压力面前被稀释。这篇文章围绕弱口令这个老生常谈的话题把定义、原理、破解逻辑、危害以及防护方案完整梳理一遍。适合三类人看一是刚入行的安全工程师需要理解口令攻击的基本链路二是运维/DBA/开发想知道自己维护的系统为什么总被盯上三是普通用户想搞清楚自己的账号在攻击者眼里到底值多少钱。全程不堆砌术语尽量用大白话把原理讲透。2. 弱口令不是只有123456识别边界与判断标准2.1 弱口令的明确定义一切能被猜出来的口令很多人的理解里弱口令就是123456、admin、password这种一眼假的组合。这个理解没错但远远不够。从攻击者的视角看弱口令的本质是可预测性。一个口令能不能被猜中取决于它是否存在于攻击者的候选清单里。这个清单可以是公开泄露的口令库、常见键盘轨迹、各种变体规则也可以是针对目标个人信息定制的社工字典。所以判断标准只有一个如果这个口令能够通过自动化工具在可接受的时间内被猜中那它就是弱口令无论它看起来多复杂。举个例子Pssw0rd看起来符合复杂口令的标准——有大写、有小写、有特殊符号、有数字——但它出现在几乎所有主流字典文件的前100条里。攻击者根本不用暴力遍历直接在字典里一查就命中了。这就是典型的看起来很强实际上弱得不行。2.2 弱口令的常见类型不只是短口令我习惯把弱口令分成五个大类这样排查的时候思路比较清晰第一类默认口令和初始口令。设备出厂自带的admin/admin应用初始化时的root/root打印机、摄像头、路由器后台的默认账号。很多设备管理员压根没改过默认口令这类最容易被批量扫描工具直接拿下。第二类纯数字短口令。123456、888888、666666、5201314这类。特点是用键盘敲起来很顺记忆成本极低。对于暴力破解工具来说6位纯数字只有100万种组合现代CPU毫秒级就能跑完。第三类与个人信息强相关的口令。姓名拼音生日、手机号后六位、工号、公司名称缩写、车牌号、伴侣或孩子的名字。这一类在定向攻击里极其致命因为攻击者只要花十几分钟翻一下你的社交媒体就能构建出一个很精准的字典。第四类键盘路径型口令。qwerty、1qaz2wsx、zxcvbnm这些是沿着键盘轨迹敲出来的输入速度快但完全在字典覆盖范围内。第五类带规律变体的口令。在基础口令上加个数字或符号比如password1、admin123!、a1234567。这类衍生规则是字典攻击里的标准策略攻击者会拿基础词去套各种常见后缀。2.3 识别口令强度的常见误区我在安全培训和项目交流中经常听到这些说法我的口令有十位够复杂了。——如果这十位是wangwei1985那跟没有口令没区别。我把生日放在中间别人猜不到的。——生日恰恰是最容易被想到的特征之一。我定期换口令三个月换一次。——如果新口令只是把abc123改成abc124那换不换没有本质区别。这些误区的共性是把复杂度等同于安全强度而实际上安全强度取决于猜测难度与泄露风险的综合评估。口令再复杂一旦出现在泄露库里或者被撞库成功安全性就归零了。3. 攻方视角下的破解逻辑为什么字典总能撞开大门讲防护之前必须先站在攻击者角度理解破解思路。这里不涉及具体攻击工具的教程只讲逻辑和原理目的是帮助大家建立正确的防御认知。3.1 撞库被忽略的隐形威胁撞库的逻辑很简单收集互联网上已泄露的账号密码组合用自动化脚本在目标系统里批量尝试登录。很多人觉得自己口令设得还行不至于被暴力破解却忽略了你用的可能是跟其他网站完全相同的口令。举个例子你在某个小型论坛注册了一个账号用了zhang123这个口令。后来这个论坛数据库泄露了攻击者拿到了明文或哈希口令。接下来攻击者会拿这批账号口令去尝试主流邮箱、网盘、企业系统、云平台。只要你在这些地方用了同一个口令账号就等于拱手相让。撞库之所以难防是因为它绕过了口令复杂度的限制——你的口令可能非常复杂但它已经泄露了复杂没有意义。这也是我在安全培训中反复强调的一点对个人而言最危险的不是弱口令而是口令复用。3.2 字典攻击为什么字典比暴力破解更高效暴力破解是穷举所有可能的字符组合但纯暴力在现实攻击中效率其实很低。一个8位大小写字母数字符号的口令空间大约有6万亿种组合就算每秒能跑10亿次也要好几个小时到几天。当然这个时间在GPU集群面前会大幅缩短但攻击者通常有更省力的选择——字典。字典文件是长期积累的人类口令行为统计库。它包含了历史上各种数据泄露事件中真实出现的口令再经过变体规则扩充。好的字典覆盖了绝大多数普通用户的思维习惯。用一句白话总结暴力破解和字典攻击的区别暴力是把整个图书馆的书翻一遍找那句台词字典是直接翻剧本里出现频率最高的那页。3.3 破解速度算力增长带来的质变提到破解速度我从实际测试数据来聊。在我做过的一次自检中一台普通配置的机器针对某个系统的口令哈希做离线破解一个6位的纯数字口令基本是秒出。8位的小写字母字母数字组合在GPU加速下也就是几分钟到几十分钟的量级。如果我用了预计算表彩虹表来加速很多常见口令连计算都可以省掉直接查表出结果。这背后是算力迭代带来的变化。口令破解非常契合GPU的并行计算架构可以同时跑海量的候选口令。云算力又让普通人也能按小时租到足够强的设备。所以我的口令够复杂破解不出来这个想法在离线攻击场景下已经越来越站不住脚了。另一个容易被忽略的向量是在线暴力破解。很多系统的登录接口没有做速率限制攻击者可以不停尝试。我见过不少业务后台管理系统的登录接口完全没有锁定机制也没有验证码。攻击者拿字典慢慢跑一晚上试几万次总有一次能碰上。这里必须强调的是讲解这些原理不是为了教人怎么攻击而是要让大家理解一个看起来还能用的口令在攻击者手里可能撑不过一顿饭的时间。3.4 人为因素社会工程学与弱口令的组合拳技术手段之外攻击者还会充分利用人为因素。比如通过公开信息收集目标单位内部员工的姓名、工号、手机号然后生成针对性的社工字典。这种字典命中率远高于通用字典因为企业内部系统常见的口令习惯就是姓名拼音工号英文名出生年月。还有一种场景攻击者通过钓鱼邮件在目标电脑上种植键盘记录程序直接记录用户敲击的明文口令。这种情况下再强的口令策略也没有意义因为问题已经超出了口令本身。弱口令治理不能只看口令策略还要跟整体安全意识培训挂钩。4. 弱口令被攻破后的放大效应从一台设备到一片网络4.1 服务器失守后的内网横移弱口令的可怕之处不在于它本身能被猜中而在于猜中之后带来的连锁反应。我在一次攻防演练中遇到过这样的情况某单位一台边缘业务系统的后台用了弱口令攻击者登录后发现这台机器上有内网其他主机的连接记录和凭据缓存。凭借这台边缘设备做跳板攻击者最终进入了核心业务网段。整个过程没有利用任何系统漏洞完全就是沿着合法路径一路走过去的。这就是所谓的横移。在攻防对抗中一台沦陷的设备足够成为攻击者在内网继续渗透的支点。如果这台设备权限够高还能抓取内存中的其他账号明文口令形成放大效应。4.2 物联网设备与弱口令的天然配对IoT设备是弱口令的重灾区。摄像头、路由器、打印机、门禁控制器、NAS这些设备通常没有键盘输入条件出厂默认口令往往非常简单用户也很少会主动修改。大量摄像头被批量扫描工具发现之后直接被拉入僵尸网络用于发起DDoS攻击。这些都是真实发生过的安全事件。IoT设备与弱口令的组合相当于把家门钥匙挂在了锁孔旁边。4.3 口令复用带来的连带灾难关于口令复用我在一次安全咨询服务中遇到过一个典型场景一家企业的一位核心员工在内部系统、个人邮箱、外部协作平台、云服务控制台都使用了相同的口令。攻击者先通过某次第三方数据泄露拿到了他在某个小众网站上的口令然后逐一尝试最终连进了云服务控制台。更关键的是他还有管理员权限可以通过控制台直接批量读取云资源、导出数据。整个过程的成本极低——攻击者可能只花了两个小时就把一个人多年的数字资产全部拿下。5. 落地防护企业侧和个人侧的系统性治理方案5.1 企业侧让弱口令无处藏身企业治理弱口令不能只靠禁止使用弱口令这句话必须有可落地的技术手段和流程约束。第一道防线口令策略的技术基线。这里不是一个简单的最小长度复杂度就能解决的。我建议的基线是关键系统强制口令长度不低于12位且支持使用较长短语普通业务系统不低于8位强制包含至少三类字符所有系统中的默认口令必须首次登录强制修改。口令策略不能只做长度要求因为password123同样满足复杂度却不安全。第二道防线登录侧的攻击缓解。所有面向互联网的系统登录接口必须启用验证码或二次校验连续失败5次锁定账号15分钟以上支持MFA多因子认证的系统一律要求管理员开启。成本不高但能有效拖慢在线猜测的速度。第三道防线主动的弱口令扫描。这里说的扫描是自检性质的安全团队定期对内部系统做口令脆弱性核验把弱口令当作漏洞来管理。扫描工具的选择方面开源的离线检测工具和商业安全评估产品都有不少选择关键是建立检测-通知-整改-复测的闭环流程。只有定期扫描才能发现那些历史遗留的弱口令。第四道防线与账号生命周期管理联动。员工离职后账号必须立刻冻结或注销外包人员权限要设定有效期共享账号尽可能杜绝如果不得不共用配合密码保险箱类工具管理访问入口。我在多个项目中的经验是弱口令整改中最阻力最大的往往是业务部门。他们会认为新的口令策略影响工作效率、耽误事。解决方式不是强硬推而是做好两类工作第一把弱口令风险具象化拿行业内真实案例做宣讲第二提供体验友好的密码管理器。与其让员工记住复杂的随机口令不如让工具来管。5.2 个人侧几个简单但足够有效的习惯对个人用户来说不需要掌握很复杂的安全知识做到下面几条就能覆盖90%的风险口令不重复核心账号邮箱、支付、云服务、社交主账号每个单独使用不同口令普通论坛类账号可以分组共享但绝不能与核心账号重复。使用口令管理器把口令交给专业的密码管理器生成和保存自己只需要记住一个主口令。主口令可以用一句只有自己知道的话加上特殊字符转换比如一句歌词、一句古诗变体。开启两步验证重要账号一律开启两步验证。攻击者即使拿到口令也过不了手机这一关。就算哪天口令泄露了也不至于立刻被登录。定期自查泄露情况利用一些公开的泄露查询服务查看自己的邮箱或手机号是否出现在历史泄露数据中。如果出现在某次泄露里且你还在其他平台用过相同口令立刻去改。5.3 口令强度自查教大家一个简单的评估方法我经常被人问你看我这个口令行不行我的判断思路是这样的第一先去主流泄露库里查一下这个口令是否出现过历史泄露第二看口令长度是否达到12位以上第三看结构是否包含无规律的字母/数字/符号组合而不是一个单词加一串数字第四看是否包含个人信息特征第五看是否与其他账号复用。以上五条任何一条不过建议就要调整。我自己用的口令大多是密码管理器生成的随机串比如kF7#mL2$qR9vT4这种长度16位以上全程不重复。虽然这种口令不好记但根本不需要记住——工具帮我们解决记忆问题。6. 我这几年在口令治理上踩过的坑和攒下的经验6.1 口令策略设得越严效果不一定越好最开始做安全体系建设的时候我一度把口令策略设得非常严格15位以上、必须包含大小写数字特殊符号、90天强制更换、不允许与历史10次口令重复。结果怎么样员工在一个便签纸上写满了口令贴在显示器旁边。这个结果讽刺但真实——口令策略太严反而逼着用户把口令明文写出来安全水平反而下降了。后来NIST更新口令安全指引时也建议不再强制用户频繁更换口令而是把重点放在口令长度和泄露检测上。现在的做法是口令长度优先复杂度适当要求登录侧配合MFA通过泄露库检测阻止已知泄露口令的使用。这个组合在防弱口令和可用性之间找到了平衡。6.2 不同系统要做口令策略分级不要对所有系统一视同仁。核心业务系统、云平台控制台、数据库这些一旦被攻破就是重大事故口令策略必须最严格强制启用MFA。普通内部管理系统策略可以适当放宽保证效率。对外展示性系统、临时环境口令要求高但可以配合更便捷的登录方式比如SSO单点登录。分级治理还有一个好处安全资源有限不可能所有系统都投入同样的检查力度分级能让你把精力集中在最关键的资产上。6.3 弱口令自检的频率与节奏边界暴露在公网的系统和内部系统自检频率要分开。公网系统建议每个月做一次内部系统建议一个季度一次临时上线或对外演示的系统上线前必须做一次。自检结果要跟工单系统打通发现问题直接派单给负责人限期整改。整改完成后再做复测确认整改有效。有个细节很多人容易忽略扫描出来的弱口令数据本身就是敏感信息。这类报告要严格控制知悉范围防止泄露后反过来被攻击者利用。我在处理这类报告时会脱敏、加密、设置访问权限。6.4 最后分享一个小技巧口令安全评估从长度入手很多朋友总喜欢纠结于口令里要不要加个感叹号、数字放在前面还是后面。根据我的经验这些细节的边际收益已经很低了。对于口令强度提升最明显、最有效的动作是拉长口令长度。密码熵值这个说法大家可能听过简单理解就是猜测口令需要尝试的次数。每增加一位长度猜测空间就扩大一个数量级。把口令从8位拉到14位哪怕只用小写字母加数字猜测难度也已经远超一个8位的高复杂度口令。我个人在检查员工口令时有一个比较简单的判断标准低于12位直接判弱12到15位看有没有明显规律16位以上即便是纯小写字母加数字也已经具备不错的基础防护力。当然前提是不能用公开的常见短语拼接。这条经验对普通用户也适用与其强迫自己记Ab2024#Zh这种难记的口令不如用一句只有自己知道的长句子的首字母组合比如去年夏天我在青岛海边捡到一枚蓝色贝壳转成qxztwzqdhbjyymlsk长度够、好记、不重复口令强度也够。再配合两步验证基本可以应对绝大多数攻击场景。弱口令治理不是一锤子买卖而是一个持续运转的过程。系统在变、人员在变、业务在变口令的安全状态随时可能退化。真正有效的办法是把检查和处理流程固化到日常运维节奏里让它成为一项例行工作而不是等出了事才想起来排查。这一点是我这些年做安全最想跟大家分享的体会。
