jwt 的 token 被获取怎么办

[nightspirit]

rt

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

[wei745359223]

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

[jackerbauer]

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

[nightspirit]

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

[nightspirit]

@jackerbauer csrf 那种么？

[Dragonphy]

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

[heyjei]

现在都是 HTTPS，为什么会被抓包呢？所以不存在这个问题

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

[preach]

nginx redis block list

[sujin190]

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

[mengdodo]

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

[jackerbauer]

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

[nightspirit]

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

[wangxiaoaer]

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

[Shing]

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

[sujin190]

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

[sujin190]

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

[des]

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

[sujin190]

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

[LGA1150]

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

[learningman]

@nightspirit 反代的时候加上 forward 头啊

[sujin190]

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