周围产生OAuth凭证的最佳实践？(Best practices around generating

我意识到， OAuth规范不指定有关ConsumerKey，ConsumerSecret，的accessToken，RequestToken，TokenSecret，或验证代码的来源，任何事情，但我很好奇，如果有创造显著安全令牌的最佳做法（特别是令牌/秘密组合）。

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

1. 只要使用与消费者/用户相关的随机字节，存放于DB
2. 哈希一些用户/用户特定的数据，存放于DB与消费者/用户关联
3. 加密用户/消费者特定数据

优点：（1）是数据库是这似乎是最安全的信息的唯一来源。 这将是很难运行针对比攻击（2）或（3）。

散列真实数据（2）将允许重新生成令牌从大概已经知道的数据。 可能没有真正提供（1）由于需要存储/查找反正任何优势。 更多的CPU密集型比（1）。

加密实际数据（3）将允许解密知道的信息。 这将需要更少的存储＆比查找潜在更少的（1）及（2），但是潜在的安全性较低为好。

是否有任何其他的方法/优点/应该考虑的缺点是什么？

编辑：另一个考虑是，必须有某种在令牌随机值的，因为必须存在到期，补发新的令牌，因此不能只由真实数据的能力。

遵循问题 ：

是否有最低令牌长度，使显著加密安全？ 据我了解，长令牌秘密会创造更安全的签名。 这是理解是否正确？

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

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

Answer 1:

OAuth的只字未提除了它具有与之相关联的秘密令牌。 所以你提到的所有方案是可行的。 我们令牌演变为网站变得更大。 下面是我们之前使用的版本，

1. 我们的第一个标志是用户名，令牌密钥和到期加密的BLOB等的问题是，我们不能在没有主机的任何记录撤销令牌。

2. 所以我们改变它存储在数据库中的一切，令牌仅仅是作为关键数据库的随机数。 它有一个用户名称索引，所以很容易可以列出用户的所有令牌和撤销它。

3. 我们得到比较少的黑客活动。 有了随机数字，我们必须去到数据库，了解如果令牌是有效的。 因此，我们再次回到了加密的BLOB。 这一次，令牌只包含密钥和到期的加密值。 因此，我们可以检测无效或过期的令牌没有去到数据库中。

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

1. 在令牌添加一个版本，所以你可以改变令牌格式不打破现有的。 我们所有的令牌有第一个字节的版本。
2. 使用Base64编码的安全网址版本编码的BLOB，这样你就不必处理URL编码的问题，这使得调试与OAuth的签名更加困难，因为你可能会看到三重编码即basestring。

Answer 2:

怎么样把IP地址的令牌？

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

也许这形式给出将针对随机生成攻击更加安全。

最好！

编辑：好吧，我想，也许我并不清楚enaugh。 我的职位是没有问题的答案。 我不会试图找到在那里我与IP地址读取实现在互联网上的文章，我同意，如果你把IP地址的令牌，使用动态IP地址还有移动连接的客户端都会有记号的问题。

文章来源: Best practices around generating OAuth tokens?