私有协议的轻量jwt-token的实现,物联网设备

jwt是优秀的无状态服务的身份验证方法。但是jwt有一个小缺点就是字符串太长,在物联网设备中占用宝贵的储存空间。

所以有一些场景下不适合。 这里分享一种 类似jwt的轻量token实现方法。

几个元素

1、身份标识:一般是物联网设备的串号、mac地址 或者其他的唯一id。下文中以mac地址为例 2、过期时间: 明文用时间戳即可,考虑到时间戳 1703981684 前面的17最近几年不会变化。也可以直接用 03981684。或者干脆为 202312311023 这种格式,然后去掉前面的20,即2312311023 代23年12约32日10点23分过期 3、长短token: 一般jwt中应用存在两个token 一个token同于频繁的通讯有效期通常是几分钟到几十分钟 称之为 accessToken ,另外一个token为长期token 用于更新token,有效期通常为几十天,称之为 refreshToken 4、盐值:因为我们简化了jwt 改为直接通过MAC地址的md5值来检查,所以需要引入一个salt来保证协议的安全性。每一个设备具有唯一的一个salt值。

逻辑

因为物联网设备 不会要求用户去登陆注册,所以两个token的更新都是无感进行的。

设备首次联网,使用设备MAC地址向 jwt-lite 服务器请求,jwt-lite检索数据库,确定mac地址在白名单中,那么发放两个token,格式为均为 过期时间+md5(过期时间+MAC+salt),其中 refreshToken 可以写入到设备的flash中,而accessToken 就暂存到ram 掉电即丢弃。

设备重新通电后,检查 refreshToken 是否将要过期或者是否存在,然后根据需要使用mac地址重新请求accessToken 和 refreshToken。随后改为定时检查

设备运行过程中,定时检查/或者每次要和服务器交互之前先检查 accessToken (和 refreshToken) 。 如果 accessToken 将要过期,但是 refreshToken 没问题,那么使用refreshToken重新请求accessToken。 refreshToken 则另外的定时逻辑处理。

加密

因为物联网设备 出厂的时候,每个设备我们可以预设一个加密key。所以上面的 过期时间+md5(过期时间+MAC+salt) 我们可以使用对称加密算法例如AES 加密一下 预防恶意第三方。当然实际意义不大。如果不考虑服务器端压力,私有协议 over tls或https 更为合理。

物联网设备端

物联网设备端,因为都是基本可信客户端,可以去掉refreshToken,只使用accessToken 并适当延长 accessToken的有效期 一般为几十分钟。

app端/web端

可以用同样的方法

安全防护

降低服务器校验开支

无状态服务器 通过redis或者内存map 维护一个 已经验证过的token list 和对应过期时间,避免每次都校验token。
这个list要定时维护清理,避免占用过多资源。

黑名单token回收已签发的token

同时维护一个黑名单token,手动或者自动,加入黑名单。

避免被反射攻击

和协议本身以及upd/tcp无关,需要在isp或者iptable处理。
SYN Flood、ACK Flood、TCP反射、UDP Flood、UDP反射 是常见的被攻击的方式。当然这和你用什么协议无关,只要是基于tcp/udp 就要面对这些。首先要想办法避免自己成为反射角色,其次要预防常见的反射攻击。 现在 主要的的反射源有 : DNS、NTP、SSDP、QOTD、SNMP、CHARGEN、LDAP、MEMCACHE、WS-DISCOVERY、DVR、CLDAP、RPC 等 主要反射源端口,基本都是上述协议的默认端口。 一般在入口流量的地方 通过白名单ip+端口 以及 指纹分析 和 带宽弹性部署 以及 eip切换 来应对

避免被自己放大攻击

在token未校验通过/不符合格式 的返回的错误消息体尽可能简短,或者直接不返回。
配合黑名单制度,即使把请求异常的token加入到黑名单

Licensed under CC BY-NC-SA 4.0
comments powered by Disqus
Built with Hugo
主题 StackJimmy 设计