jwt 存在的无状态的安全问题与解决方案

背景

• jwt是无状态的,除了自动失效之外无法手动过期

举个例子:

• 当我们的token泄露或者密码泄露,别人冒充自己做一些非法操作(比如删除自己的作品)
• 这时候我们无法让账号强行下线,会存在安全隐患

我的需求

解决密码泄露/token泄露无法强制下线的安全问题

解决方法

方案1:黑名单

• 当用户密码泄露或者token泄露时,将用户加入黑名单,限制用户的操作

存在的问题

举个例子:

• token的有效期是1天,
• 用户token泄露,将用户加入黑名单,用户花了1小时修改密码,并移出黑名单(用户需要正常使用)
• 但是泄露的旧的token依旧有效,非法用户可以继续操作

解决方案

• 双重验证
  • 先验证是否黑名单
  • 再验证token的颁发时间是否在密码修改时间之后

问题

• 整套逻辑会变得比较复杂,并且一次访问需要验证两次redis(使用lua可以一次性验证),性能还不如使用session

成本估算:

• 条件: 100万总QPS,我们使用了redis的lua脚本,每次需要一次请求redis
• redis压力100万QPS
• redis性能瓶颈: 10wQPS;按50%的cpu使用率是比较安全的,每台机器5wQPS
• 需要机器数量: 100w/5w=20台
• 每台机器成本: 2000元/月
  总成本: 2000*20=40000元/月

方案2: 双token刷新

• 用户登录时,生成两个token,一个是正常的token,一个是刷新token,刷新token的有效期是1天,正常token的有效期是5s
• 当正常token失效时,用户可以使用刷新token重新生成一个新的正常token

核心解决的问题

• 提高用户的体验(不会再使用中突然下线,因为token可以自动刷新)

存在的问题

• 只能解决正常(短期)token泄露的问题(有效期短,别人拿到就已经过期了),刷新token泄露/密码泄露无法解决

方案3: token与session结合

• 根据方案2的思路,我们可以将token与session结合
• 当用户登录时,生成一个token,有效期是5s; 同时生成一个session,存在 redis中有效期1天,每次使用自动续期

工作原理:

• 请求时使用token,token失效时,使用session刷新token

泄露的情况与解决方案

• token泄露: token有效期短,别人拿到就已经过期了
• session泄露: 可以手动删除,限制用户的操作
• 密码泄露: 删除session,限制用户的操作;将用户更改为异常状态,限制用户登录(MySQL层)

这样我们就解决了密码泄露/token泄露无法强制下线的安全问题

成本估算

• 条件: 100万总QPS
• token验证不需要请求redis,只有使用session时才需要请求redis
• redis压力分摊到5秒钟,redis的压力20wQPS
• redis性能瓶颈: 10wQPS;按50%的cpu使用率是比较安全的,每台机器5wQPS
• 需要机器数量: 20w/5w=4台
• 每台机器成本: 2000元/月
  总成本: 2000*4=8000元/月

成本比方案1低了80%

方案4: 长连接(websocket)

实现原理:

• 创建长链接(websocket)的时候需要进行验证(比如:使用 session 验证),
• 创建连接之后保持与服务端的连接,请求就不再需要鉴权了

优点:

• 减少反复的鉴权的开销
• 主动推送信息(高实时性)

缺点:

• 长连接会占用服务器资源，连接数过多时可能导致性能问题。

安全问题
密码泄露:

• 删除 session,标记用户状态
  session 泄露:
• 没有用,一个 session 只允许一个连接,只要之前的没有断开,其他的使用 session 连接不上.

可以更好的解决安全问题,还可以进行安全警告(比如异地登录,异设备登录等等),告知客户有人正在非法访问他的账号.