security - 生成 OAuth token 的最佳实践？

Question

我意识到 OAuth spec没有指定有关 ConsumerKey、ConsumerSecret、AccessToken、RequestToken、TokenSecret 或 Verifier 代码的来源的任何内容，但我很好奇是否有任何创建高度安全的 token (尤其是 token / secret 组合)的最佳实践。

据我所知，有几种创建 token 的方法:

1. 仅使用随机字节，存储在与消费者/用户关联的数据库中
2. 对一些用户/消费者特定的数据进行哈希处理，存储在与消费者/用户关联的数据库中
3. 加密用户/消费者特定数据

(1) 的优点是数据库是唯一的信息来源，这似乎是最安全的。与(2)或(3)相比，攻击会更困难。

对真实数据进行哈希处理 (2) 将允许根据可能已知的数据重新生成 token 。可能不会真正为(1)提供任何优势，因为无论如何都需要存储/查找。比 (1) 更密集的 CPU。

加密真实数据 (3) 将允许解密以了解信息。与 (1) 和 (2) 相比，这需要更少的存储空间和可能更少的查找，但安全性也可能较低。

还有其他需要考虑的方法/优点/缺点吗？

编辑:另一个考虑因素是 token 中必须有某种随机值，因为必须具有过期和重新发行新 token 的能力，因此它不能仅由真实数据组成。

继续提问:

是否有最小 token 长度来确保显着的加密安全？据我了解，更长的 token secret 将创建更安全的签名。这种理解正确吗？

从散列的角度来看，使用特定编码比使用另一种编码有优势吗？例如，我看到很多 API 使用十六进制编码(例如 GUID 字符串)。在 OAuth 签名算法中， token 用作字符串。使用十六进制字符串时，可用字符集比使用 Base64 编码要小得多(更可预测)。在我看来，对于两个长度相等的字符串，具有较大字符集的字符串将具有更好/更广泛的哈希分布。在我看来，这会提高安全性。这个假设正确吗？

OAuth 规范在 11.10 Entropy of Secrets 中提出了这个问题。 .

Answer 1

OAuth 没有提及任何关于 token 的信息，只是它有一个与之关联的 secret 。所以你提到的所有方案都可行。随着网站规模的扩大，我们的代币也在不断发展。这是我们之前使用的版本，

1. 我们的第一个 token 是一个加密的 BLOB，包含用户名、 token secret 和过期时间等。问题是我们无法在主机上没有任何记录的情况下撤销 token 。

2. 因此我们将其更改为将所有内容存储在数据库中，而 token 只是一个用作数据库 key 的随机数。它有一个用户名索引，因此可以轻松列出用户的所有 token 并撤销它。

3. 我们很少遇到黑客事件。使用随机数，我们必须去数据库才能知道 token 是否有效。所以我们再次回到加密的 BLOB。这次， token 仅包含 key 的加密值和过期时间。因此我们可以检测无效或过期的 token ，而无需访问数据库。

一些可能对您有帮助的实现细节，

1. 在 token 中添加版本，以便您可以更改 token 格式而不破坏现有格式。我们所有的 token 都有第一个字节作为版本。
2. 使用 URL 安全版本的 Base64 对 BLOB 进行编码，这样您就不必处理 URL 编码问题，这会使使用 OAuth 签名进行调试变得更加困难，因为您可能会看到三重编码的基本字符串。