JWT 安全性讨论

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2723 天前的主题，其中的信息可能已经有所发展或是发生改变。

了解了一下 JWT 协议，对于多端统一处理，服务端不用保存，还是蛮看好的。

但是也有疑问，客户端在拿到服务器签发的 JWT 后，如果客户端被拦截，Head 里面的 JWT 不修改，篡改 Body 里面的数据，服务端也会通过。

如果保证这点呢？

jwt

客户端

head

body

33 条回复 • 2017-07-20 08:56:31 +08:00

Miy4mori

2017-07-17 14:56:22 +08:00 via iPhone

这点基本不在这种 token 类的考虑内，那是 https 的事。

hcwhan

2017-07-17 15:11:02 +08:00 via iPhone

jwt 里面可以加上 ip 字段

RubyJack

2017-07-17 15:18:30 +08:00

这个问题 session 也存在啊，都被中间人了就只能上 https

lshero

2017-07-17 15:49:00 +08:00

body 的数据没有签名嘛？

janyw

2017-07-17 15:54:21 +08:00

@lshero 一样的。你既然能在客户端签名，那一样可以被劫持

janyw

2017-07-17 15:54:33 +08:00

@RubyJack 也对哈

janyw

2017-07-17 15:54:40 +08:00

@Miy4mori 说的在理

lshero

2017-07-17 15:56:57 +08:00

@janyw 签名是校验数据完整性的，服务端和客户端都预留了密钥，中间人不知道密钥的话篡改数据后怎么生成对应新数据的签名啊？

janyw

2017-07-17 17:05:52 +08:00

@lshero 客户端预留密钥，你怎么保证密钥不丢

lion9527

2017-07-17 17:36:57 +08:00

所有的加密解密都在服务端完成，客户端为什么要保留秘钥？

honeycomb

2017-07-17 17:40:59 +08:00

@janyw

“你既然能在客户端签名，那一样可以被劫持”
“客户端预留密钥，你怎么保证密钥不丢”

这里的讨论应该是建立在客户端用于签名的密钥没有失窃的基础上，此时中间人不知道密钥，无法对签名所保护的内容进行篡改。

所以问题出在 @lshero 说的 HTTP body 没有签名。

至于保护客户端的密钥，则是另一件事情了。比方说你可以把 key 的存储 /使用通过硬件支持的 KeyStore 完成

wancaibida

2017-07-17 18:29:02 +08:00 via iPhone

jwt+jwe 啊

ChefIsAwesome

2017-07-17 18:58:15 +08:00

https://stackoverflow.com/questions/20963273/spa-best-practices-for-authentication-and-session-management/21175036#21175036

简单讲，先上 HTTPs 再说

zouqiang

2017-07-17 19:03:53 +08:00

签名肯定得服务端，https 是必须的，+IP，前端的话可以再考虑加 fingerprint

reus

2017-07-17 19:05:05 +08:00

客户端没有密钥，客户端不能签名，所以客户端不能篡改，就是这么安全。
惟一的问题是，token 泄漏之后，你没法让它失效。

zonghua

2017-07-17 19:57:49 +08:00 via iPhone

@reus 所以设置更短的过期时间？

qclaogui

2017-07-17 19:58:36 +08:00

吓得我又在项目里测了好几遍，“篡改 Body 里面的数据，服务端会通过“？？ LZ 可否给个列子, 几遍测下来并没有发现异常

lemayi

2017-07-17 20:52:12 +08:00

搭个车问一下。前端，不是 app。js 里面没办法存 scret_key，怎么来防止重放攻击呢？

hantsy

2017-07-17 22:12:39 +08:00

@reus JWT 可以有时效，不要太长。如果结合 OAuth2，在前端 SPA 中可以自动用 refresh_token 去刷新。

rrfeng

2017-07-17 22:13:27 +08:00

这个不是 jwt 能解决的问题。是 https 的事。

hantsy

2017-07-17 22:14:22 +08:00

@hcwhan 不如在 Request 中再一个 XSFS Token 验证。

Suclogger

2017-07-18 00:49:09 +08:00

客户端的密钥无法保证丢失，用 https 也没用，无法抵御中间人攻击，所以这也是我不愿意使用 jwt 的原因，虽然他很简洁，很适合在微服务环境做认证

kylin511

2017-07-18 07:38:06 +08:00 via iPhone

可以用 PoP token

reus

2017-07-18 08:33:24 +08:00

@zonghua 短了客户要频繁验证，一天不登录又要验证，长了危险期又很长

liujun5065

2017-07-18 10:07:49 +08:00

JWT 是方便授权的，只要保证不能被伪造就行了。防劫持那是另外的问题。防中间人劫持可以使用 https。防客户端劫持可以缩短有效时间，可以使用加密硬件，这个需要分情况。支付宝类就可以把时间限制的很短，比如一次交易时间内。v2ex 这种就随便了，设置个一年都没问题。

ltye

2017-07-18 11:07:28 +08:00

payloads 的签名是在服务端完成的，校验也是，没太看明白篡改有什么用，改的了 payloads 也改不了签名啊，除非渗透了服务器拿到配置里的 secret key

janyw

2017-07-18 14:46:08 +08:00

@wancaibida jwe 是个啥？

janyw

2017-07-18 14:46:51 +08:00

@ltye 比如 body 是 A 给 B 转账 100 元。篡改为 A 给 C 转账 100 元

maze1024

2017-07-18 22:03:07 +08:00

@qclaogui 哈哈哈，我看到也吓一跳，明明第三段是校验前两端的，楼主怎么做到修改中间段而能通过校验，难道没有加盐？

maze1024

2017-07-18 22:07:52 +08:00

@janyw 客户端无法修改 payloads 的，并且 payloads 不能存放敏感数据，因为是 base64 在客户端可以转化明文，敏感有风险。另外你修改第一或第二段任何数值之后，就和第三段的校验不符合了，是不可能通过服务端验证的。jwt 就相当于是一个令牌，用来确定访问权限的，不是用来传递重要数据的。

ykwlv

2017-07-19 16:46:44 +08:00

@Suclogger jwt 本来就是只在服务器端签名吧，你把密钥放客户端，肯定是会丢的啊。

Suclogger

2017-07-19 17:14:30 +08:00

@ykwlv 公钥必然是放在客户端的，不然怎么加签，公钥暴露意味请求可以被构造

ltye

2017-07-20 08:56:31 +08:00

@janyw 这样用 jwt 不合适吧，对于客户端来讲 jwt 就是一个字符串，不需要知道编码前的内容，只需要根据规则存储 /更新 /向服务器提交即可，如何编制 payloads 是服务端的工作。

JWT 安全性 讨论

JWT 安全性讨论