问题:使用 MongoDB 生成的 _ids 作为“秘密数据”(例如,OAuth Tokens)

MongoDB_id字段是否足够随机/不可猜测以充当秘密数据?

例如:如果我正在构建服务器端 OAuth,我可以使用 _id 作为用户的 OAuth 令牌吗?我想这样做是因为它为数据库提供了清洁度和可索引性(例如,“tokens._id”u003d> oauth_token)。

检查 MongoDB _id 对象的结构,它们似乎是相当随机的,但我确实对恶意实体暴力猜测一个存在一些挥之不去的担忧。

解答

简而言之,没有。 MongoObjectIds很容易猜到。特别是在高负载下,这些通常是连续的数字,因为时间戳、机器和进程 ID 不会改变。如果你看的结构 Objectid,它们是由

a 4-byte timestamp, 
a 3-byte machine identifier, 
a 2-byte process id, and 
a 3-byte counter, starting with a random value.

因此,它们几乎没有随机性。我经常在数据库中看到连续的 id,例如,如果某个控制器操作写入域对象,以及快速连续的日志条目。

如果时间戳可以猜到并且机器 id 是可确定的(除非你有一个巨大的集群),那么就只剩下五个字节了。通过查看许多生成的 id,我可能可以将其减少到 50 个进程,因此有效熵在 28 位范围内。这仍然很难猜测,但对于访问令牌来说风险太大。

改用加密强的伪随机数生成器并从中创建令牌。例如,在 .NET 中,RNGCryptoServiceProvider允许创建任意长度的随机数据。

作为旁注,我建议在您的 OAuth 令牌周围添加一个额外的加密包装器,原因有两个:

a) 您希望能够快速确定无效令牌。有效的加密 shell 可能仍包含无效令牌(已撤销或过期的授权),但您不必每次都对数据库进行暴力攻击。另外,客户端

b) 客户可以一遍又一遍地请求令牌。虽然这不是必需的,但我所知道的几乎所有系统每次都会返回不同的令牌(无论它们是否是自我验证的)。通常,这是因为令牌本身的有效期有限。这与 OAuth 授权的有效期不同。

在数据库中,您真正要存储的是授权,即某个用户授予某个客户端的权限。如果删除此授权,则所有令牌都将无效。每次都插入一个新令牌非常不方便,因为用户必须删除所有令牌才能有效地删除应用程序授权。