采用的是授权机制,access_token
token 生成原理是用户的
唯一 id + md5(用户设备 ip + 浏览器信息)
然后进行 rsa 加密 生成 token
但是用户 ip 和浏览器信息很容易模拟出来,大家头脑风暴下思考下有什么更好的方式~
1
Miy4mori 2017-07-26 19:15:06 +08:00 via iPhone 1
mac 地址,IMEI,UUID
|
2
whileFalse 2017-07-26 20:35:01 +08:00 1
请说明场景和需求。
|
4
swulling 2017-07-26 22:07:28 +08:00 1
手机验证码
|
5
am241 2017-07-26 22:08:28 +08:00 1
加一个计数器,每次调用自加 1
encrypt(' session_token + counter') = request_token, 用户设备之间同步 counter 还是不太容易的 |
6
gdtv 2017-07-26 22:08:48 +08:00 1
这是世界性难题,无解。
|
7
gdtv 2017-07-26 22:09:06 +08:00 1
用户 ip 很容易模拟出来?请问怎么模拟?
|
8
Miy4mori 2017-07-26 22:33:14 +08:00 1
@hoythan 要么 client 发送一个能标识唯一身份的,要么你开个 websocket 连接,限制同 IP 的连接。
|
10
FanWall 2017-07-26 23:17:01 +08:00 2
世界性难题+1
我经常做这些唯一数据的模拟,也就是所谓 fp,js 中一般[我所遇到的]是利用 canvas 指纹、cpu、分辨率、可视区、字体列表、插件列表、鼠标轨迹等等再配合 timestamp 等进行加密(不要以为 RSA 就很安全,和加密算法没有任何关系,甚至,你自己随便写一点 xor 在这个场景下都比 RSA 好,因为在混淆后会极大地增加分析难度)提交,最后的防护是混淆甚至动态混淆。 也有一些第三方服务商,例如同盾科技、网易易盾等。 反作弊还可以配合 wss、flash,增加一些分析难度。 然鹅。。。这些都只是防一防普通人,只要有利可图,都是很容易破的。 所以作为一个菜鸟级别的逆向爱好者,我只有一个建议,不要把验证唯一性的逻辑 [全部] 交给客户端。(以上词汇主要来自经验,不严谨的地方请包涵指正。) |
11
LeeSeoung 2017-07-27 10:37:59 +08:00 1
同意楼上,只能混淆加大分析难度,客户端的 token 生成对于破解者来说毫无意义。知道了你的生成规则再拼接也可以模拟的。
|
12
hoythan OP |