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

[kid1412621]

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

[IamNotShady]

@kid1412621 https://github.com/shanehughes3/uuid62

[momocraft]

要绝对唯一往往就需要生成算法是决定性 (提前生成好也是一种决定性)。再要短就容易被枚举。

几十个 bit 足够在在现实的概率上唯一了，比如 https://alex7kom.github.io/nano-nanoid-cc/

[sun522198558]

短网址那种做法
不想自己做短网址服务，可以自己每个用户的 url 去短网址服务申请一个短网址取短网址的最后几位存入自己的数据库
偷懒做法

[zhenjiachen]

我是直接把用户 ID 和活动 ID 拼接，然后中间家几个分隔符，再 md5
然后把 md5 的值和用户 id 还有活动 ID 存数据库。

[troywinter]

没必要过度设计，snowflake 已经是相当广泛应用过的 id 生成算法，碰撞不用考虑，对外暴露 id 加 salt 加密就可以了，只要不把原始 id 暴露出来就可以，等有人攻击你们系统了，也就有钱搞这些了

[kid1412621]

@troywinter 感谢分享，我觉得我的问题应该变成暴露用户 id 是否有隐患。

根据这里（ https://stackoverflow.com/questions/3629134/should-i-expose-a-user-id-to-public ），一般应用直接暴露 id 应该没事，我看好多网站也是暴露了的。当然具体情况具体分析，我这里的需求可能不能直接暴露，因为 id 和兑换码联系了起来，要防止被枚举。
我的想法是这样，还是简单些做，用户注册的时候用 snowflake 生成的 id 做一遍 hash 或 encode，这样至少不是直接暴露 id，然后存到 db 做个 index， 兑换时（用户的分享码就是别人的兑换码，需求是这样 = =）再用这个码去找是否存在。
不知这样妥否，有无可以优化的地方。

[kid1412621]

@IamNotShady 有点疑问，我在线（ http://encode-base62.nichabi.com ）转了下，发现和这个库的结果不一样呢

[kid1412621]

@zhenjiachen 同意，简单直接，不过我这需求有些不一样