在NodeJS,Crypto Token身份验证环境中生成唯一令牌

Dan*_*y D 8 node.js cryptojs

使用nodejs和crypto,现在,当用户登录时,我生成一个随机身份验证令牌:

var token = crypto.randomBytes(16).toString('hex');
Run Code Online (Sandbox Code Playgroud)

我知道这不太可能,但两个令牌的可能性很小.

这意味着用户理论上可以在另一个帐户上进行身份验证.

现在,我看到两个明显的方法来传递这个:

  • 当我生成令牌时,查询用户的数据库并查看是否已存在具有相同值的令牌.如果是的话,只需生成另一个.如您所见,这是不完美的,因为我正在向数据库添加查询.
  • 由于每个用户在我的数据库中都有唯一的用户名,因此我可以
    使用用户名作为秘密生成器密钥生成随机令牌.这样,两个令牌就没有办法具有相同的价值.可以加密吗?它安全吗?

你会怎么做?

Mac*_*cil 16

它不太可能担心它偶然发生.我不会牺牲性能来锁定并检查数据库.

考虑一下Pro Git中关于20字节SHA-1总和之间随机冲突的可能性的摘录:

这是一个示例,让您了解如何获得SHA-1碰撞[偶然].如果地球上所有65亿人都在进行编程,而每一秒,每一个人都生成的代码相当于整个Linux内核历史(100万Git对​​象)并将其推入一个巨大的Git存储库,则需要5年时间该存储库包含足够的对象,以使单个SHA-1对象发生碰撞的概率为50%.[平均项目]存在一个概率较高的概率,即你的编程团队的每个成员都会在同一天晚上被无关紧要的事件中的狼袭击和杀死.

(现在可以直接构造 SHA-1冲突,因此引用现在不太适用于SHA-1,但在考虑随机值的冲突时它仍然有效.)

如果您仍然担心这种可能性,那么您可以轻松地使用更多随机字节而不是16.

但关于你的第二个想法:如果你用随机用户名对随机ID进行哈希处理,那么该哈希可能会发生冲突,就像随机ID一样.你还没有解决任何问题.

  • 您的服务器在两个用户之间随机生成令牌冲突的机会远小于有动机的恶意用户猜测另一个用户令牌的机会。如果您认为第一种情况是潜在问题,那么您应该相信第二种情况更像是一个问题,并通过使用更多随机字节来解决它。如果您认为 16 个字节可能足以阻止有动机的暴力攻击者猜测目标用户的令牌,那么它应该遵循 16 个字节可能足以阻止您的服务器产生冲突。 (3认同)