[我，秦，给赞] api 接口如何验证用户设备的绝对唯一性

[hoythan]

采用的是授权机制，access_token

token 生成原理是用户的

唯一 id + md5(用户设备 ip + 浏览器信息)

然后进行 rsa 加密 生成 token

但是用户 ip 和浏览器信息很容易模拟出来，大家头脑风暴下思考下有什么更好的方式～

[Miy4mori]

mac 地址，IMEI，UUID

[whileFalse]

请说明场景和需求。

[hoythan]

@Miy4mori 网页获取不到这个。

[swulling]

手机验证码

[am241]

加一个计数器，每次调用自加 1

encrypt(' session_token + counter') = request_token， 用户设备之间同步 counter 还是不太容易的

[gdtv]

这是世界性难题，无解。

[gdtv]

用户 ip 很容易模拟出来？请问怎么模拟？

[Miy4mori]

@hoythan 要么 client 发送一个能标识唯一身份的，要么你开个 websocket 连接，限制同 IP 的连接。

[Miy4mori]

@hoythan 单单无状态的接口基本做不到这个

[FanWall]

世界性难题+1
我经常做这些唯一数据的模拟，也就是所谓 fp，js 中一般[我所遇到的]是利用 canvas 指纹、cpu、分辨率、可视区、字体列表、插件列表、鼠标轨迹等等再配合 timestamp 等进行加密（不要以为 RSA 就很安全，和加密算法没有任何关系，甚至，你自己随便写一点 xor 在这个场景下都比 RSA 好，因为在混淆后会极大地增加分析难度）提交，最后的防护是混淆甚至动态混淆。
也有一些第三方服务商，例如同盾科技、网易易盾等。
反作弊还可以配合 wss、flash，增加一些分析难度。
然鹅。。。这些都只是防一防普通人，只要有利可图，都是很容易破的。
所以作为一个菜鸟级别的逆向爱好者，我只有一个建议，不要把验证唯一性的逻辑 [全部] 交给客户端。（以上词汇主要来自经验，不严谨的地方请包涵指正。）

[LeeSeoung]

同意楼上，只能混淆加大分析难度，客户端的 token 生成对于破解者来说毫无意义。知道了你的生成规则再拼接也可以模拟的。

[hoythan]

@LeeSeoung
@FanWall
模拟 token 是不可能的，有生成机制，因为这里我担心模拟设备和 id，所以其他内容我简化了。

[LeeSeoung]

@hoythan 你的生成机制是在客户端么，是的话，那就可以被模拟。

[hoythan]

@LeeSeoung 客户端信息+用户 id rsa 加密后取其中随机 6 个字符拼接 26 个随机生成字符串 变成一个 32 位 accesstoken 存放在内存缓存中，所以 token 是模拟不出来的。只能获取。