生成OAuth令牌的最佳做法？

Question

我意识到OAuth规范没有指定任何关于ConsumerKey，ConsumerSecret，AccessToken，RequestToken，TokenSecret或Verifier代码的来源，但我很好奇是否有任何创建显着安全令牌的最佳实践（特别是令牌/秘密组合）。

在我看来，创建令牌有几种方法：

1. 只需使用随机字节，存储在与消费者/用户相关的数据库中
2. 散列一些用户/消费者特定数据，存储在与消费者/用户相关联的数据库中
3. 加密用户/特定于消费者的数据

（1）的优点是数据库是看起来最安全的信息的唯一来源。 对（2）或（3）进行攻击会更难。

散列实数据（2）将允许从可能已知的数据重新生成令牌。 可能没有真正为（1）提供任何优势，因为无论如何都需要存储/查找。 比（1）更多的CPU密集型。

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

是否还有其他方法/优点/缺点需要考虑？

编辑：另一个考虑因素是令牌中必须有某种随机值，因为必须存在过期和重新发行新令牌的能力，因此它不能只包含真实数据。

关注问题 ：

是否有最小的令牌长度，以显着加密安全？ 据我了解，更长的令牌秘密会创建更安全的签名。 这种理解是否正确？

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

OAuth规范在11.10熵的熵中提出了这个问题。

Answer 1

OAuth没有说明令牌，只是它有一个与之相关的秘密。 所以你提到的所有方案都可行。 随着网站变得更大，我们的令牌也随之发展。 以下是我们以前使用过的版本，

1. 我们的第一个令牌是带有用户名，令牌密钥和过期等的加密BLOB。问题是我们无法在主机上没有任何记录的情况下撤销令牌。

2. 所以我们将其更改为将所有内容存储在数据库中，令牌只是一个随机数，用作数据库的密钥。 它有一个用户名索引，因此很容易列出用户的所有令牌并撤销它。

3. 我们得到的黑客活动很少。 使用随机数，我们必须转到数据库以了解令牌是否有效。 所以我们又回到了加密的BLOB。 这次，令牌只包含密钥和到期的加密值。 因此，我们可以在不进入数据库的情况下检测无效或过期的令牌。

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

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

Answer 2

将ip地址放入令牌怎么样？

然后你可以在每个请求解密令牌并检查请求IP地址与令牌IP地址。

也许这种方法可以更安全地抵御随机生成的攻击。

最好！

编辑：好吧我想也许我不清楚enaugh。 我的帖子问题不是答案。 我不会试图在互联网上找到我用IP地址阅读实现的文章，我同意如果你把IP地址放在令牌中，那么拥有动态ip地址和移动连接的客户端就会有令牌问题。