做安全这几年凡是真正动手做过授权测试的朋友最后都会有一个共识身份认证是整个系统里最容易被低估、也最容易翻车的一环。窗口期、弱口令、硬编码密钥、会话固定、MFA绕过……攻击者不一定非要找到高深的漏洞很多时候只要一个设计不严的登录接口就够了。这篇文章会从身份认证攻击的底层逻辑讲起结合Kali Linux里常用的工具Hydra、Medusa、John、Hashcat、Burp Suite、sqlmap 等拆解它们的实战姿势、使用场景和我自己踩过的坑最后落到防御侧——你怎么用最小成本把这条路堵上。适合刚接触 Web 安全或渗透测试的同学以及负责业务系统安全的开发和运维朋友。所有演示都建立在自己搭建的靶机环境里不要在未经授权的目标上做任何尝试。1. 认证攻击的底层逻辑1.1 拆掉“认证盒子”你到底在打什么每个系统认证组件都可以拆成四块凭证用户名、密码、指纹、证书等、校验逻辑后端如何比对、如何存储、会话登录成功后的状态标识、信任链第三方登录、SSO、OpenID Connect 等。攻击者真正寻找的是这四块里某一块能被操控的点。举个最直观的例子很多 Web 登录框看起来只有一个表单但实际背后有密码重置接口、验证码接口、注册接口、第三方回调接口。攻击者会先做整站指纹和入口枚举把认证边界全部摸清。不要只盯着那个最显眼的登录框。比如我曾经遇到一个后台主入口防护做得很严既有账号锁定又有验证码但密码重置接口存在逻辑缺陷攻击者直接改了响应包就能绕过重置步骤。所以真正的攻击面往往是那些容易被忽略的“隐藏认证点”。认证机制的校验逻辑也很关键。有些系统把密码明文存在数据库里有些用 MD5 不加盐有些用了 bcrypt 但没有限制尝试频率。这些差异决定了攻击成本遇到 bcrypt单 GPU 每秒只能尝试几千次遇到 MD5 加盐不合理每秒则可以跑到几十亿次。1.2 攻击路径不止一条在线爆破、离线破解、认证绕过、会话攻击做攻击面梳理时我习惯把认证攻击分成四条路径在线猜测直接对认证接口发送用户名/密码组合利用弱口令、默认口令、密码喷洒等方式尝试进入。离线破解先通过某种手段拿到用户的密码散列hash再到本地环境里用 CPU/GPU 做高强度的碰撞。认证绕过利用注入、逻辑缺陷、反序列化等漏洞直接跳过校验过程根本不需要“猜密码”。会话攻击通过固定会话、劫持 Cookie、重放已认证请求来盗用他人的登录状态。为什么要先分路径因为很多新人一上来就挂上 Hydra 跑爆破结果触发账号锁定反而把自己锁在门外。合格的测试人员会在出发前先评估目标系统的认证实现选择成本最低、噪音最小、成功率最高的那条路。比如目标已经上了验证码 限流就不会死磕在线爆破而是去看是否存在接口逻辑绕过又比如目标系统支持 Windows 域认证那么离线抓取 NTLMv2 散列后用 hashcat 破解可能比在线尝试有效得多。1.3 从“拿到一个密码”到“控制整个系统”的攻击链路认证攻击并不是孤立的技术它只是整条攻击链路的起点。常规流程是资产发现 → 找到认证入口 → 获取合法凭证或绕过认证 → 登录进入系统 → 维持会话 → 权限提升 → 横向移动。我参与过的一次授权测试里最开始只是发现了一个管理后台存在默认口令登录后拿到一个文件上传功能通过上传恶意文件获得 WebShell再利用内网跳板访问到数据库主机。整个过程中身份认证是第一道门而这道门的钥匙是“admin/admin”这种谁都能猜到的默认组合。这件事给防御方一个警示只加固前台的用户登录是不够的内部系统的默认口令、服务账号的弱口令、配置文件里写死的数据库密码都是身份认证攻击的突破口。攻击者只要有任意一个有效身份就能在系统内部逐渐移动。1.4 授权边界不是口号动手之前先确认范围这里必须先说一句因为很重要对任何非授权目标进行登录爆破、密码喷洒或凭证破解都是违法行为。我所有下文的演示都在自己搭建的虚拟机靶场环境中完成。对真实系统进行测试前一定要有明确的授权书写明目标 IP、时间窗口、允许的测试方式和应急联系人。有人可能觉得“我只是用 Hydra 试试密码不算什么”。但登录爆破会触发目标账号锁定会影响线上业务会给对方安全团队留下大量错误日志。如果出了问题第一责任就是发起流量的人。所以尊重授权范围不只是为了合规也是保护自己的专业信誉。2. 在线口令攻击实战Hydra、Medusa 与密码喷洒2.1 Hydra 基础用法协议、字典与并发控制Hydra 大概是 Kali Linux 里在线口令攻击最常用的工具支持 SSH、FTP、SMB、HTTP、HTTPS、POP3、IMAP、RDP 等几十种协议。关键参数并不复杂hydra -L users.txt -P pass.txt 192.168.1.100 ssh -t 4 -f这里-L指定用户名列表-P指定密码列表目标 IP 后面紧跟协议类型-t是并发线程数-f表示找到第一个有效口令后停止。如果 SSH 跑在非默认端口需要加-s 2222指定端口。对于 HTTP 表单登录要先抓包分析请求结构再用类似这样hydra -L users.txt -P pass.txt 192.168.1.100 http-post-form /login:username^USER^password^PASS^:Fincorrecthttp-post-form后面依次是登录 URL、POST 数据体^USER^和^PASS^是占位符、以及判断登录失败的标志字符串。这里比较容易出错建议先用 Burp Suite 抓包确认参数名和失败响应内容。并发数千万不能贪多。默认 16 个线程看着很爽但如果目标带宽有限会产生大量超时如果目标有账号锁定策略你等于用最快的速度帮管理员把所有账号全部锁死。我个人一般先试-t 4观察目标响应时间再逐渐往上加最多到 8。目标若是内网的简单 SSH 服务可以放宽到 16但如果有 WAF 或应用层防护还是慢一点更稳。2.2 在线攻击的三大痛点锁定、限速、验证码在线爆破最大的敌人不是加密强度而是业务系统的风控策略。第一个痛点是账号锁定。如果系统明确是“每账号连续失败 5 次锁定 30 分钟”你跑 1000 个密码前 5 次错误后这个账号就不能用了。破解效率再高也拿不到机会。所以先做策略探测手工输入两三次错误密码观察是否出现锁定提示、验证码或延迟变长。如果存在强锁定要么放弃在线爆破要么转成密码喷洒——后面会讲。第二个痛点是限速和验证码。很多系统会对同一源 IP 的请求频率做限制达到阈值弹验证码甚至直接把 IP 加入黑名单。这种情况 Hydra 的价值就很低了因为验证码需要单独识别成本远高于收益。第三个痛点是日志噪音。每一次爆破尝试都会在目标系统留下大量认证失败记录SIEM 里会形成明显告警。如果你做的是红队测试需要尽可能低调那么“在线爆破”本身就不是好选择。真正可落地的做法是先通过情报收集拿到一批真实账号名再用低频率密码喷洒把失败率控制在业务基线之内。2.3 比“硬爆”更聪明密码喷洒实操思路密码喷洒Password Spraying的核心是“用少量常见密码去撞大量账号”而不是“对单个账号尝试大量密码”。很多账号锁定策略只针对同一账号的连续失败次数却不会因为不同账号使用同一个密码而触发锁定。攻击者可以先通过招聘平台、企业信息、接口枚举等方式收集到一批用户名然后选一个季度常见密码比如Spring2024或Company2023!对每个账号依次尝试一次。Kali 里用 Hydra 做喷洒其实就是像这样交替用户名和密码hydra -L users.txt -p Spring2024 target http-post-form /login:username^USER^password^PASS^:Fincorrect -t 1 -f注意这里密码用固定值-p线程数尽量低模拟正常用户登录。更稳妥的写法是写个小脚本每隔几秒尝试一次每次换一个账号。喷洒密码选词特别讲究不要拿 rockyou 里那些“123456”越是复杂的业务系统越要使用“符合密码复杂度要求但又不随机”的口令比如包含首字母年份特殊符号的组合。这类密码往往是安全策略倒逼用户形成的习惯。我在实际测试里靠密码喷洒打进去过好几个项目。最典型的一次是目标公司要求所有员工密码至少 12 位且包含大小写数字结果喷洒Admin12345678这种常见模式时居然真的撞中了两个管理员账号。这侧面说明复杂度要求并不会让密码变得更随机只会让用户在一堆固定模式里选一个。3. 离线凭证破解John、Hashcat 与规则字典3.1 拿到散列才有底气离线破解的凭证获取路径在线攻击要跟目标系统实时交互效率低、风险高。离线破解的思路完全不同先把密码散列抓到本地然后慢慢算。这一步的关键在于“怎么拿到散列”。常见途径有几类无线网络握手包抓取 WPA2 四次握手包或 PMKID得到 PSK 的验证数据可以在本地跑字典。内网协议抓取利用同一网段内的中间人攻击、模拟服务等方式诱使其主机发起认证请求保存下 NTLMv2 等散列。Kali 里像 Responder 这类工具经常被用来做这一步。主机文件读取拿到系统权限后读取 Linux 的/etc/shadow、Windows 的 SAM 文件、浏览器保存的登录数据、服务器配置文件里的硬编码口令。数据库泄露目标数据库被拖走后里面的用户表密码散列会被直接用来做横向破解。拿到散列后攻击就变成了“算”而不是“猜”。对防御方来说这条链路意味着密码存储方案如果不合理货币一样的东西就会被批量破解。比如 MySQL 老版本里的PASSWORD()函数、不带盐的 MD5、DES 加密的 NTLM在 GPU 面前都属于“秒破”。3.2 John the Ripper 快速上手格式识别与规则利用Kali 自带 John the RipperJtR适合在 CPU 环境下快速跑常见散列。最基础的使用方式john --wordlist/usr/share/wordlists/rockyou.txt hash.txt如果散列格式不确定可以先看支持列表john --listformats | grep -i ntNTLM 对应ntbcrypt 对应bcryptLinux shadow 可以先通过unshadow passwd shadow unshadow.txt合并账户文件再交给 John 处理。关于 rockyou.txt很多新手第一次用就报错因为它在 Kali 里是个压缩包。先解压sudo gunzip /usr/share/wordlists/rockyou.txt.gzJtR 的强大之处在于规则。比如对字典里的每个词自动加上常见年份或后辍john --wordlistdic.txt --rulesAll hash.txt这比直接用原始字典多命中 3 到 5 倍。规则机制背后其实是“人在生成密码时有规律可循”大多数要求的“强密码”最终都逃不出某几个模式。对防御方来说这也是为什么说“密码复杂度检查”不能只看表面。3.3 HashcatGPU 加速与掩码攻击实战如果散列量比较大或者密码是复杂的 NTLM/WPA 类型我会优先用 Hashcat。它支持 OpenCL/CUDA能调起显卡并行计算速度比 CPU 快几个数量级。常用命令hashcat -m 1000 ntlm_hash.txt rockyou.txt-m是散列类型1000 对应 NTLM22000 对应 WPA-PBKDF2-PMKID3200 对应 bcrypt13100 对应 Kerberoast 的 TGS-REP。不确定时可以查hashcat --example-hashes里面有每种类型的示例散列和格式说明。掩码攻击适合密码模式固定但不知道具体内容的情况。比如想跑 8 位纯数字密码hashcat -m 1000 ntlm_hash.txt -a 3 ?d?d?d?d?d?d?d?d?d代表数字?l小写字母?u大写字母?s特殊符号?a任意字符。掩码可以组合比如一个常见模式是“首字母大写 6 位小写 2 位数字”hashcat -m 1000 hash.txt -a 3 ?u?l?l?l?l?l?l?d?d需要注意的是掩码空间会随长度爆炸式增长。8 位纯数字只有 1 亿种组合单卡很容易但 8 位大小写字母加数字就是 62 的 8 次方非常不现实。所以掩码攻击只适用于你了解到目标某个密码规律之后针对性缩小范围。3.4 规则和自定义字典为什么你的字典跑不出结果很多人只下了一个 rockyou然后直接跑跑不出来就认为目标密码很安全。实际上问题出在字典和规则上。经典字典只能覆盖通用弱口令真实业务里的口令往往带企业和个体特征。这时候要用工具做定制字典。Kali 里的cewl可以爬取目标网站的文本生成与业务相关的词表cewl https://target.example.com -w company_words.txt再把爬到的词交给 Hashcat 的规则跑。比如用best64.rule对基础词做年份、符号、大小写混合等变形hashcat -m 1000 hash.txt company_words.txt -r /usr/share/hashcat/rules/best64.rule另外也可以用crunch按字符集和长度生成字典比如生成“6 位数字 两位符号”的密码crunch 8 8 0123456789!#$ -t %%%%%%%%^^ -o custom_mask.txt不过 crunch 生成的字典体积往往很大我一般只在已知部分模式时用否则存储和 IO 会成为瓶颈。总体思路是先跑高频弱口令再跑规则变形最后用定制词表。顺序错了效率会差很远。4. 认证绕过与 Web 会话攻击4.1 不在登录框上死磕SQL 注入与接口逻辑绕过爆破是体力活认证绕过是技术活。真正高价值目标是那些能直接跳过认证过程的逻辑漏洞。历史上最常见的是 SQL 注入登录框。比如后端代码把用户名直接拼进 SQLSELECT * FROM users WHERE username admin AND password xxx如果在用户名框输入admin --注释符号会把后面的密码条件完全注释掉在某些数据库里就会直接匹配 admin 用户。这种注入在现在的主流开发框架里已经很少见因为参数化查询被普及了。但仍有不少历史系统、二次开发系统还在踩这个坑。除了注入还有很多逻辑绕过思路密码重置流程缺陷验证码直接存在于响应包中或者修改手机号/邮箱字段后重置链接发给攻击者。登录接口返回包篡改某些系统用successfalse表示失败有心人抓包改成successtrue后端竟然不做二次校验。注册接口越权可以注册管理员角色或者给已有账号提升权限。未授权访问登录后的接口没有做鉴权直接请求/admin/api/users能带出数据。测试这些点不需要重型工具一个 Burp Suite 或者浏览器开发者工具就够了。Kali 里也可以配合 sqlmap 做自动化验证sqlmap -u https://target.com/login.php --datausernameadminpassword1 --level2 --risk2但不要完全依赖自动化。很多逻辑漏洞需要手工分析流程比如重置步骤能不能跳过验证码是否可以复用响应包中隐藏字段是否可控。4.2 会话固定、劫持与重放Burp Suite 现场操作Web 登录成功后使用的 Session Cookie 同样是认证的一个环节。攻击者如果拿到一个有效 Session就能直接冒充用户。常见的攻击方式有会话固定攻击者先自己登录得到一个有效的 Session ID然后诱导受害者使用这个 ID 登录登录后 Session 不更换攻击者就能共享这个会话。会话劫持通过 XSS 窃取 Cookie或通过抓包工具在网络上嗅探明文 Cookie。重放攻击把截获的合法请求原封不动地再发送一次。比如免登录接口的请求可能不校验时间戳或随机数能被无限重放。用 Burp Suite 测试时我会重点看三个属性Set-Cookie是否带HttpOnly、Secure、SameSite。如果 Cookie 没有HttpOnly页面里的 JavaScript 就能用document.cookie读出如果登录成功后 Session ID 没有变化则可能存在会话固定问题。实操中我还遇到过一种很有意思的重放一个支付平台的“确认订单”接口没有做幂等控制同样的请求发十遍就生成十个订单直接打穿了业务逻辑。虽然这和严格意义的认证攻击不同但暴露出的问题本质是“信任了一个已经认证过的请求却没有做上下文校验”。防御端通常需要加入随机 token、时间戳、来源 IP 绑定等机制。4.3 客户端校验的假安全感很多前端项目在登录表单里做了加密比如用 JavaScript 对密码做 MD5/SHA 后传输开发者觉得这样就是安全的。但攻击者完全可以不经过前端直接调用后端接口或者把前端加密后的结果抓包替换成已知值。客户端校验只能防普通用户防不了任何有抓包能力的人。同样前端显示“验证码正确”也并不意味着后端一定校验了。我见过一个系统在响应中把验证码字段删掉了前端判断为空就跳过但后端根本没有做二次校验。这类问题用 Burp 的 Repeater 改几个参数就能发现。防御一侧永远要记住安全边界在后端。前端只能做体验优化不能做安全决策。5. 从攻击视角反推防御清单5.1 防线上移密码健康度与存储安全既然攻击者能枚举、能喷洒、能离线算最直接的防御就是把“可计算的密码”变得不可计算。密码存储方面规范做法是使用 bcrypt、scrypt、Argon2 等慢哈希算法而不是 MD5、SHA1 这类快速哈希。慢哈希意味着攻击者在拿到散列后每秒尝试次数会被压缩几个数量级。同时必须加随机盐避免相同密码得到相同散列也避免使用彩虹表。密码策略方面与其强制要求 12 位包含大小写数字符号不如引导用户使用多词短句passphrase同时强制检查新密码是否在已知泄露密码列表中。Kali 里也可以装cracklib之类的库做弱口令过滤。记住复杂度要求并不消除规律只能逼用户把规律用得更多样。真正的强口令是“随机且不重复”所以推荐密码管理器。5.2 账号锁定与 MFA不要一刀切在线爆破依赖“可以无限尝试”所以锁定和限流是有效手段。但硬锁定会有个副作用攻击者可以利用锁定策略去锁死所有账号制造业务拒绝服务。我见过不少企业为了防爆破设置了“三次错误锁账号”结果被攻击者用自动化遍历账号全锁了业务直接停摆。更好的方案是分层应对第一次失败不锁定只增加验证码连续失败次数增加后先要求二次因素再延迟下一次尝试时间最后才做临时锁定。锁定可以只针对“同一个账号 不同源 IP”或“同一源 IP 不同账号”设置阈值尽量减少误伤真实用户。MFA 是必须项。TOTPGoogle Authenticator 这类能挡住口令猜测和喷洒但对网络钓鱼仍然有效性有限。真正抗钓鱼的是 WebAuthn/FIDO2 硬件密钥它绑定了站点域名。短信验证码容易被 SIM 卡劫持不适合作为唯一第二因素。至少做到所有管理后台、所有远程访问通道都强制 MFA。5.3 日志监控与异常行为告警攻击工具产生的痕迹其实在日志里很容易看到。同一个源 IP 在短期内出现大量认证失败、同一账号在多个 IP 上短时间内尝试登录、非工作时段登录成功、管理员账号首次登录后执行敏感操作……这些都是监控规则的切入点。建议至少做三件事全量记录认证成功、失败、锁定的日志保留 180 天以上。建立基础告警规则失败次数突增、登录结果异常、来自陌生国家或地区的认证成功。设置“蜜标账号”创建几个几乎不会被正常使用的账号比如svc_honeypot这些账号一旦登录直接通知安全团队。蜜标的价值在于即使攻击者拿到了合法凭证也会在第一时间触发告警。如果有条件还可以把认证日志接入 SIEM 或日志分析平台做变量组合检测。比如“账号是 admin 协议是 SSH 来源 IP 从未出现过 操作是下载数据库备份”这种组合几乎必然是高风险。5.4 安全编码规范从源头减少认证痛点很多认证攻击之所以有效是因为代码层面根本没有“统一认证”的概念。每个系统都自己写登录逻辑有的验证码校验在后端有的在前端有的连密码都不会加密。防御端最节约成本的改进是建立安全编码规范所有登录、注册、密码重置接口必须走统一认证服务不能各自实现一份“记住我”逻辑。所有 SQL 查询使用参数化预编译杜绝字符串拼接。密码传输使用 HTTPS服务端散列存储不能明文落库。登录成功、退出、重置密码时都重新生成 Session ID废弃旧会话。Cookie 设置HttpOnly; Secure; SameSiteLax/Strict必要时绑定 IP/User-Agent。敏感操作改密、转账、删除需要二次认证不能只看 Session。所有响应内容默认转义防止 XSS 窃取会话。这些规范看起来都是老生常谈但我在大量测试项目里发现真正做齐的非常少。很多时候是某一个小系统或者一个老接口没跟上导致整条防线被撕开。我个人在实际项目里的体会是纯工具堆砌解决不了问题攻击测试的关键是先理解目标系统的认证结构和业务逻辑。Kali 里那些工具只是提高效率的手脚真正有价值的是对“认证到底在信任什么”的判断。防御也一样不要只看到登录框和密码要把会话、接口、第三方信任链乃至运维入口都拉进来一起看。每次用 Hydra 或 Hashcat 破解出一个密码我都会提醒自己这背后是人性的弱点也是流程和编码的问题。堵住这些点比盲目上一个昂贵的安全设备更实在。