jwt 的 token 被获取怎么办

admin 管理员组

文章数量: 887021

jwt 签发后，每次请求会续期，如果 token 被抓包后，别人得到后，有没有好的方案解决身份窃取问抗投诉服务器题？

签发 token 的时候加入一些验证信息，比如 IP
如果当前 request IP 和签发时候的 IP 不一致就加 blacklist 里

不嫌麻烦的话，搞一个验签。拿到 token 也没有

ip 这种也想过，不过，做不了，因为，我们是多个子系统的，后端需要请求 uc，那么每次来的都是后端 ip

csrf 那种么？

插眼，目前方案是一定时间失效再申请

现在都是 HTTPS，为什么会被抓包呢？所以不存在这个问题
你要说是在用户设备上抓包，那么他都拿到了用户的物理机器，这个应该不在防范的考虑范围之内吧。就跟你拿到服务器的实体，可以不输密码重启进入安全模式一样

nginx redis block list

手机移动的话是不是要被坑死，动不动被踢出来，这方案一看就不靠谱啊

要么 token 里加 ip 这些参数做二次校验，要么缩短 token 时间，走刷新 token 流程

jwt token 这里主要作用应该是登录身份验证，验签主要作用识别敌我，看是不是我们的人请求过来了，给 API 加个签名

我们公司卖软件，要安装到客户机器上，他们可能不用 https 协议

传统 cookie+session 的方式，cookie 被抓包怎么办？ 不是所有的网络层攻击都能靠应用层解决。

下发包含 refresh_token 的，强制 3600s access_token 过期，如果要使 access_token 不过期，就用 refresh_token 去刷新，如果都过期了就重新登录吧

想要完全防止这种的话似乎只能在服务器端记录一个校验信息了，保证只有最后一次签发的能校验通过，其他的都拒掉，然后用专门的接口一小段时间后来续期就可以吧

传统 cookie+session 的模式中，服务器 session 里一般会记录校验信息，每次刷新到新的会更新校验信息，就算 cookie 抓包一会就失效了，就现实来说按顺序抓到所有包再次拿到刷新后的 cookie 的可能毕竟要困难上好几个数量级的

没有不靠谱啊，我见到过的都是基于 AS Number 识别的

既然能抓你 jwt 就不能抓你签名密钥了？所以签名在这种情况下并不能防劫持

用登录密码作为签名密钥，修改密码后之前签发的 token 就失效了

反代的时候加上 forward 头啊

是么？ AS Number 怎么说？一般能抓包劫持的肯定是在相同网络来源里的，不能区分吧，再者移动设备 wifi 切到 4g，ip 肯定变啊，你总不能这样就退出登录了吧

如果希望用 IP 方案的话，了解一下 X-Forwarded-For，整个链路上所有节点都遵守这个标准能解决很多问题。
不过用 IP 方案可能也解决不了你的问题，因为要考虑有些客户端会变 IP 的，一变 IP 就重新登录可能体验也不好。
可以考虑加个互踢，token 泄露一次，用户只需要重新登录就可以让以前泄露的 token 及其刷新产生的 token 全都失效。
token 这种方案其实保证使用 HTTPS 通信的话，一般是没问题的，客户侧的安全问题只能由客户自己解决，除非你提供专用终端。
另外就是可以增加偷到 token 后的使用难度，比如前端混淆代码对 token 和 payload 做个公钥签名，token 和签名一起发，后端私钥验证签名错误则认为 token 无效，只要你的混淆代码难以被逆向或外部调用，破解成本就会很高。

以前我的一些项目只是设置了一个刷新机制，token 有效期内被盗用挺无解的~

jwt 是无 server 的，注定没办法实现这种功能，如果想实现黑名单必定要破坏 jwt 的无 server，那其实和 cookie 也就没什么两样了。

有同样困惑，蹲一个。
JWT 因为 token 丢失就无法防范，造成 token 也不敢给太长时间。导致用户隔不久就得重新登录。这个体验缺陷不太好接受。

看看钉钉机器人的加签认证，developers.dingtalk/document/app/custom-robot-access

如果是拿着 token 做爬虫，那么可以随机在页面上做校验，如果是用模拟点击方式爬虫，那没办法，只能一定时间内限量请求。。。

加了 https 后能泄露的，都是故意把 token 提取出来的，这种你没办法再防了，是用户自己在攻击自己

你如果能知道这个 token 已经被盗了，那就是需要做 token 的黑名单，如果你不知道这个 token 是不是被盗了，那和 jwt 没啥关系。

有缘人啊，参考如下
Token Sidejacking¶
Symptom¶
This attack occurs when a token has been intercepted/stolen by an attacker and they use it to gain access to the system using targeted user identity.
How to Prevent¶
A way to prevent it is to add a “user context” in the token. A user context will be composed of the following information:
A random string that will be generated during the authentication phase. It will be sent to the client as an hardened cookie (flags: HttpOnly + Secure + SameSite + cookie prefixes).
A SHA256 hash of the random string will be stored in the token (instead of the raw value) in order to prevent any XSS issues allowing the attacker to read the random string value and setting the expected cookie.
IP addresses should not be used because there are some legitimate situations in which the IP address can change during the same session. For example, when an user accesses an application through their mobile device and the mobile operator changes during the exchange, then the IP address

解决不了。如果他想抓你包的话。
你这个问题背后，实际上背后是一个很大的问题，也可以说，不是问题。

个人认为，ip 可能会变，不可取。https 也照样抓包。
可以考虑再加盐 sign，然后再加上时间戳和随机字符串防重放。

如果没有 HTTPS 的话，和 JWT 没有任何关系，即使你每次都走验证流程，账号密码依然可能被中间人拿到，其结果是一致的，因此假设客户端、服务端可信，而信道不可信，则需要使用类似 HTTPS 的解决方案，比如应用发出请求时就 AES 一遍，如果客户端与信道均不可信，那么此题无解

加个黑名单就是了

这就是无脑用 JWT 的后果了。。。简单的说，JWT 不适合楼主这种需求。换成自己的轮子吧，用服务端存 Token 的虎符模式，别用 JWT 的这种无服务端的印信模式。
什么是虎符？古代将军领兵的信物。一半在实际掌握军队的军官手上，一半由皇帝临时授予领兵作战的指挥官。军官看到指挥官拿的虎符能与自己的合为一体，就听从指挥官的命令，否则就把骗子抓起来。
什么是印信？就是古代皇帝授予行政官员某地行政管理权的凭证。地方上官员认印不认人，所以西游记里面强盗杀了唐僧他爹，夺了印信就能堂而皇之地去上任。

“每次请求会续期” 这就是问题所在。
JWT 和 Session 的本质区别是什么？是 JWT 设计目的是“不需要中央服务器即可验证有效性”；签发在中央服务器，验证在业务服务器，不需要和签发服务器交互。由于其本质是离线验证，因此无法吊销。有那些个闲人搞出来 JWT 吊销机制完全破坏了这个设计目的，纯属闲的，直接用 Session 不好么。
那么如果不用那些个闲的卵疼的吊销机制，JWT 就只能使用“拒绝续期”机制。把 JWT 有效期设置得短一点，然后要求客户端频繁去「中央服务器」续期。当身份窃取时就拒绝续期。
而 LZ 是“每次请求会续期”，这说明什么？说明业务服务器能续期啊！这种行为完全破坏了续期机制的意义，还不如设置一个一百年的有效期，省得麻烦。

量子通信

https

曾经有个三哥面试官问过我这个问题
我说没办法
因为 jwt 不过存储，我发吊销
他表示不满意，但也没说怎么做
真没想到是个三哥

要存储的 jwt 就变成了 session 注:存储 jwt 的黑名单一样是存储

好好的 cookie + session 方案你不用，学人家玩 token 。无状态 token 身份认证轻量是真的轻量，但弊端也不少啊。如果加入服务端续期什么，那还不如直接用 cookie + session，强行使用只不过造了个轮子。结合实际需求，选择技术方案。

我发现现在凡是 token 就是 JWT……也不管合适不合适。完全就是滥用

都能被抓包了，还有什么干不了的？

都能被抓包了，还有什么干不了的？ +1
你做软件安全，总有个约束范围。 抓包侵害的是单个用户，不值得花大气力保护；
如果你涉及到资金等重要业务，可以加二次验证。 比如发送短信验证码，验证通过才能完成转账的动作。

access token 和 refresh token
access token 时间短些

也有疑问，插眼

我觉得主要原因是一堆开源的快速开发平台使用了 jwt token 做无状态的身份认证，以至于带起了这股风气。而为什么这些快速开发平台选择了 jwt token,应该是前后端分离后，后端接口用 token 好调试，前端调用后端因为跨域，用 token 也方便。既然如此方便，那就这么办，至于带来的问题，如续期、token 签发时间过长导致不安全等问题，那就不考虑了，其实大部分软件也都不在乎，只要能过等保就好。至于突然 token 到期，用户强制重新登录这种体验问题，那不是问题，因为我们做的系统就几乎没人用，用也不会用很久。实在不行 token 签发时间给个几天，或者先做出来再说，后面再考虑打补丁，从无状态改成有状态，后端记录一下 token,给它续期得了。

随便搞个 mitmproxy 就能抓 https 了

普通 JWT 不需要 Refresh Token 。OAuth 才需要。注意他们的区别：

1. JWT 基本只用于对客户端的授权；特别的，经常用于浏览器并可以直接写入 Cookie 。而 OAuth 则经常用于对服务器的授权。
   客户端业务逻辑除了将 JWT 发送给真正的目标之外，几乎不会将 Token 或记录到别的地方。也就是说只要本机安全（由用户自行保证）、传输层安全（ TLS ），Token 就丢不了。甚至对于浏览器来说，业务逻辑可能都看不到 JWT 的 Token 。
   服务器拿到 Token 之后就不一样了，可能传输到其他服务器或存储到中间件中、可能写入日志。单一的业务逻辑很难控制。这种情况下，使用单独的、业务层不可见的 Refresh Token 就能显著提高安全性。
2. 对于客户端来说，只有用户在操作客户端时才可能发生刷新失败事件。这时候用户只要重新登录就好了；而服务器用 Token 刷新失败则可能是灾难性事件。比如当 OAuth 用于 CI 系统的拉代码逻辑，当 Token 过期且意外刷新失败时，整个 CI 都无法工作了，必须召唤管理员上线处理。这导致 OAuth 必须有一个强健的刷新逻辑。

结合业务场景设计，有的被截取也无所谓，像新闻接口基本都是 GET，展示数据的。只要保证业务安全，请求是幂等的就可以。返回的数据中有用户敏感数据就要加密

https

JWT 的能力是很有限的, 参考这个帖子里的讨论
https://stackoverflow/questions/21978658/invalidating-json-web-tokens
Truly stateless JWT authentication cannot be achieved for a typical, real world web app because stateless JWT does not have a way to provide immediate and secure support for the following important use cases:
User’s account is deleted/blocked/suspended.
User’s password is changed.
User’s roles or permissions are changed.
User is logged out by admin.
Any other application critical data in the JWT token is changed by the site admin.
You cannot wait for token expiration in these cases. The token invalidation must occur immediately. Also, you cannot trust the client not to keep and use a copy of the old token, whether with malicious intent or not.

无解 微博至今都没解决掉这个问题

HTTPS 不是抓不到包，而是流量被加密了，如果遇到上游证书欺骗和不安全的加密方法依然可以解出来。。

建议 JWT 不要滥用，JWT 有它适合的场景的，这种需要吊销 token 的根本不适合用 JWT，一旦需要吊销，就意味着服务端需要保存相关信息，那还不如直接用 cookie+session 或者自己造轮子了

https 是加密码的 你要解出来才有用

所以说呢？加密了还是能抓包啊，先把证书抓下来就可以了。回帖之前你去用过我说的东西了吗

“换成自己的轮子吧，用服务端存 Token 的虎符模式”
能说说哪些 Token 虎符模式 的轮子比较好么?
自己造轮子的话，我的理解是: backend 的所有 services 里面得有个专门的 authentication service, 这个 auth service 通过认证 user 的主 key (e.g. password) 给用户生成 token (with expiration time). 然后, user 试图连接任何 edge services 的时候 (edge services 是我临时取的名字, 算是所有在 server mesh 边界, 链接 client users 的那些 services), edge services 都会去认证 user message 附带的 token. edge service 可以每次都去 authentication service 认证 user token, 也可以 cache user tokens 到自己 service node 上, 当然如果允许 cache user tokens 的话, auth service 撤销(revoke) user tokens 的时候, auth service 必须通知有可能 cache 过相关 user tokens 的所有 edge service nodes.

在我的 github 里面可以看到我自造的轮子。

我最近也正好做了一个 jwt token 签 ip 的需求，实际应用下来，略为鸡肋

机智如我，开个新主题听听大家怎么看 jwt 做会话身份认证
https://www.v2ex/t/774127#reply23

公私钥，对端公钥加密。

别搞那么多花样 SSL 是最稳的 诞生的目的就是为了解决不可信网络的可信通信
如果不支持 SSL 那就自己网络层加上公私加密 毕竟是经过全球验证的可靠通信算法

JWT 固然只是其中一个用户请求识别机制，还得配合其他手段判断是否异地或者换设备

系统安全不应该由一个小小的令牌来承受……被盗 1 次和 n 次是没区别的。

其实你的顾虑和 jwt 没关系，Cookie 认证同样有被抓包的风险，只要明确这一点再来想解决方案。
其实方案之一前面有说了，可以验证 IP，反代也是可以拿到 IP 的，需要让后端把 IP 通过 HTTP 头等方式传给你。

https：你当我不存在？
jwt：这个锅我不背。
所以为什么会被抓包？

好的

现在很少固态 IP 吧

用 https 就不怕被抓包了，卖软件给客户的时候就告知这点，不用后果自付。

JWT 的使用范围很窄
当然楼主的问题用 ssl 就行

jwt 被盗不久相当于账号密码被盗么？根据一样的逻辑处理就好了

一、token 有一个刷新有效期的，这个有效期过了，是无法进行刷新的。
二、用户反馈账号被盗后，应该要禁止用户登录。
三、将当前有效期内的 token 全部列入黑名单。

我就搞不懂了，为啥老是看到用 jwt 来做业务系统的身份认证呢（是用到业务系统上了把？应该把）？

非常赞同 老哥，我也看了不少开源系统，介绍中的技术选型，老是有 jwt 。
我个人 认为 jwt 的应用场景 非常狭窄，并不适合用来做 “XXX 管理系统”、“XXX 电商系统”，之类的。 有个场景，我觉得还是比较合适的，用户邮箱注册完，会有一封激活邮件，这个激活邮件中的激活地址后面跟的一串字符串，大概率是 JWT 的字符串。而且有效期可能就 4 小时，甚至 2 小时。
为什么呢？ 因为首先，就算邮件泄露，能造成什么损失？ 激活链接点进去，还需要比如一些关键信息的校验的。 甚至进去的页面中，姓名（昵称）之类的，都是脱敏的。其次，有效期也很短。最后的最后，这类邮件就算疯狂的发，对主业务系统没有任何影响。
当然如果有其他的 JWT 的应用场景也可以讨论一下，反正我是非常不赞成在业务系统中走 JWT 的，只有在一些 非重点（不一定是非重点，反正有个度把）的业务功能中，才可能有 JWT 。 业务系统还是 老老实实的 session （分布式 session ） ，或者 类似于 session 的 token 模式。

自定义 token 的模式不好吗，想单点登录，多端登录或者强制刷新都是可控的

Jwt 的应用场景是很小的，现在大部分的所谓 Jwt 都是伪 Jwt，很多系统还是存在中心验证服务器的。

70 多条评论看完了，说句实在话，楼主的问题是 JWT token 被获取后引发的一系列安全问题，我们以问题为导向进行反推，获取 token 必定存在一系列利益影响，试问，如果你的软件没有引发别人的利益，为何要获取你的 token 呢？ 难道只是闲的无聊？ 那么问题又来了，有利益存在，获取你的 token 进行下一步操作，是为了满足某个利益达成。如果没有利益别人也要获取你的 token，那基本上是无解，说的清楚点就是没有绝对的安全可言，token 只是一个签名用来校验你的服务的，仅仅是对自己的服务来说有一定安全校验，也只是达到了自己骗自己的目的，我可以第一时间获取你的 token 并解密后通过 token 解析的信息进行一系列的操作，这些都是可以反推的。

面试官：请你先回答在浏览器输入 URL 地址后，都发生了什么吧。

个人认为 JWT + 中心验证服务器的模式没有问题。个人实践中，将部分会话状态数据存放于 JWT 中来减少服务端的状态数据存储需求；中心验证服务器仅负责对 token 的有效性进行验证。
与自定义 token 模式进行对比，使用 JWT 作为 token 在主要认证逻辑上没有太大区别；优势在于将数据存储移到客户端后，减少了服务端在还原会话状态时所需的 IO 次数。至于对系统性能是否有根本影响，就见仁见智了。

上面说滥用 jwt 的我觉得很奇怪
jwt 只是一种可验证的信息签发传输方案. 你要在里面存储什么信息, 服务端如何利用完全是开发者自己的选择.
就算所谓要替代 cookie+session, jwt 可以替代的是 cookie 部分而不是整个 cookie+session. 纯 cookie 也是可以做无状态无 session 的身份验证方案的.
lz 的问题里就是服务端无状态导致无法踢人. 那就得重新做有状态认证方案了. jwt 可以+session 或者 anythin else 可用的服务端状态.

同感。问题和 jwt 根本没有关系，抓包的场景下，cookie 中的 session 不也同样能被抓包么。而且奇怪的是，为何很多人觉得加上刷新机制后就能防止抓包呢，刷新过程不也会被抓包么。我认为关键还是在于解决抓包。

解决中间人抓包（比如路由器抓包）：上 https，这样可以防止中间人抓包。
解决客户端抓包（比如爬虫）：本质上是人机识别，用验证码、行为识别那套。
以上和 session 、jwt 刷新都是无关的。

动态 token 里面包含一些验证信息， 比如 session 类信息，ip bind 类信息， 指纹类信息， 时间类信息（动态更新）， 把这些信息编码， 代码一定要做一些混淆或加密。ip 类目前国内的网络环境不可靠， 有的 ip 是集体 ip 有的是浏览器自己中转的流量。

这和 jwt 没关系，本质上是传输层不安全导致身份识别令牌泄漏，用不用 jwt，设置多久吊销，有没有黑名单，只要不解决传输层不安全的问题，无解。

你要想的是为啥会被抓包，https 就不需要考虑被抓包了；

无解

jwt 解决的是用户是否已认证的问题，你的问题是用户究竟是不是他本人，这是两个事

考虑场景：一般情况下，用户是长期登录的，而且认证信息不会被轻易被盗，但是仍然存在一部分用户有登出账户的需求（手机被丢等）。
相对于当前长期在线的用户而言，需要登出的用户只是很少的一部分。（这跟现在的证书颁发是很相似的，大多数人都会妥善存储私钥，但是仍然有一部分人的私钥马大哈丢失了）
这时候可以使用 jwt 作为用户令牌，使用 redis 等来存储被吊销的 jwt id 。
这样做主要是可以有效的减少热数据的数据库大小，降低对数据库系统的压力。而且，这个吊销列表也完全没有必要实时更新，隔一段时间向认证服务器更新一下数据即可。
如果你的应用用户量并不是很大，或者对登出的实时性要求很高（银行类），jwt 其实并不是一个适合你的方案，随机生成一个 token 可能更好。

非常正确，这道问题我没看懂和 JWT 有什么关系

合到 token 了 refresh_token 应该也能拿到吧，这样，就直接完蛋了吧

这类比虎符模式怎么理解？指挥官去皇帝领凭证，去军官验证，验证过了获得指挥军队的资源。我怎么看就是 jwt 呀。

服务器为啥一直续期。。一个 token 用一辈子？这样不好吧。。
1 、选择客户端续期
2 、选择添加一个 refresh_token 参考 Spring Security

本文标签： jwt token