有关生成OAuth令牌的最佳做法？

 

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

正如我所看到的，创建令牌有几种方法：

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

    • （1）的优点是数据库是似乎最安全的信息的唯一来源。 比（2）或（3）更难对其进行攻击。

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

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

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

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

    关注问题 ：

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

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

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

    OAuth没有提及任何关于令牌的内容，只是它有一个与之相关的秘密。 所以你提到的所有方案都会起作用。 我们的令牌随着网站变大而演变。 这里是我们以前使用的版本，

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

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

  • 我们获得的黑客活动非常少。 随机数字，我们必须去数据库，以了解令牌是否有效。 所以我们又回到了加密的BLOB。 这一次，令牌只包含密钥和过期的加密值。 所以我们可以检测无效或过期的令牌，而不必去数据库。

    • 一些实施细节可以帮助你，

  • 在令牌中添加一个版本，以便您可以更改令牌格式而不破坏现有的令牌格式。 我们所有的令牌都有第一个字节的版本。
  • 使用URL安全版本的Base64来编码BLOB，因此您不必处理URL编码问题，这使得使用OAuth签名进行调试变得更加困难，因为您可能会看到三重编码的basestring。

    • 把ip地址放在令牌里怎么样？

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

    也许这个问题对于随机生成的攻击会更安全。

    最好！

    编辑：好吧，我想也许我不清楚笑。 我的帖子不是问题的答案。 我不会尝试在互联网上查找有关IP地址实现的文章，并且我同意如果您将IP地址放在令牌中，那么具有动态IP地址和移动连接的客户端将具有令牌问题。

    链接地址: http://www.djcxy.com/p/48023.html

    上一篇: Best practices around generating OAuth tokens?

    下一篇: Oauth refresh token provider error in ValidateClientAuthentication