活动分享码直接使用 snowflake 生成的 ID 是否存在什么安全隐患？

[kid1412621]

分享码和用户绑定，唯一且固定，无其它额外需求。

[momocraft]

snowflake 的设计目的是短且（无恶意使用时）避免碰撞。

如果被枚举也没关系就没关系，否则可能 hash/uuid4 好一些。

[kid1412621]

@momocraft 谢谢, 但为什么会好些呢? uuid4 我看是降低碰撞, snowflake 应该是能完全避免碰撞吧(1s 内多少次)

[IamNotShady]

维护好机器 ID 和数据中心 ID 一般没问题

[kid1412621]

@momocraft 有点懂了,是否是因为 snowflake 的生成是可预测的呢?就有可能被枚举来使用

[kid1412621]

@IamNotShady 嗯, 如果这个 id 同时是用户在系统中的唯一标识, 会有什么设计上的缺陷吗?

[Mithril]

@kid1412621 最好不要暴露这个 ID，会有安全隐患。这个值可以被猜到，也可以自己计算出来一个可能不存在的 ID。如果你其他地方没有全部做好验证，那就可能给你插进来几条错误数据。
直接随机对称加密一下就好了。

[IamNotShady]

@kid1412621 一楼说的对 我没认真审题 这种需求场景不适合用 snowflake hash/uuid4 是更好的选择

[kid1412621]

@Mithril 嗯, 但为什么要对称加密呢? secure hash 呢?

[kid1412621]

@IamNotShady @momocraft
再谢, 但 uuid 有些过长了, 有什么好的方式变短些并保证唯一性吗?

[ryV60s]

hashids 是否符合需求。

[LeeSeoung]

可以看下 zfb 订单号

[IamNotShady]

@kid1412621 UUID 可以指定长度的

[kid1412621]

@ryV60s 看来下感觉不错, 我看文档说不用每次存 db, 通过每次加解密, 想问下你们项目使用也是类似需求吗? 是这么处理的

[kid1412621]

@LeeSeoung 那个感觉不太符合这场景, 而且也没必要过度设计

[ryV60s]

@kid1412621 #13 对啊 逻辑层面加密解密的，跟 db 没关系的。前端 id 都是用这个，防止爬虫遍历。

[kid1412621]

@IamNotShady 咦, 这倒第一次听说, uuid 不是规范吗? 这么指定长度呢? 不是截取吧?

[kid1412621]

@ryV60s 只是 id 用吗? 我这里需求是分享码呀,要在个人信息中返回, 不会每次返回都算一遍吧(不考虑缓存的话)

[ryV60s]

@kid1412621 #17 你们这需求简单点的话，直接用用户数据库 id 直接加密当分享码，前端传过来再解密就是用户数据库 id，至于具体逻辑看你们需求了。

我们是后端输出 id 给前端统一加密，前端传 id 过来后端统一处理解密，暂时是每个涉及 id 的接口都得处理加密解密。
当然需要不需要解密加密，缓存得看具体逻辑了。

[IamNotShady]

@kid1412621 sorry 没说清楚 可以压缩 https://github.com/raven-im/raven/blob/master/raven-common/src/main/java/com/raven/common/utils/UidUtil.java 可以参考这个

[IamNotShady]

@kid1412621 如果你用 base62 可以压的更短