生成OAuth令牌的最佳做法？ [英] Best practices around generating OAuth tokens?

问题描述

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

如我所见，创建令牌有几种方法：

1. 只需使用随机字节，存储在与消费者/用户相关联的数据库


2. 将某些用户/消费者特定的数据，存储在与消费者/用户相关联的数据库中


3. 加密用户/具体数据

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

哈希实际数据（2）将允许从大概已知的重新生成令牌数据。可能没有真正提供任何优点（1），因为需要存储/查找。比（1）更多的CPU密集度。

加密真实数据（3）将允许解密来了解信息。这将需要较少的存储和比（1）& （2），但可能不太安全。

有什么其他方法/优点/缺点应该考虑吗？

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

关注问题：

是否有最小的令牌长度使密码安全吗？据我所知，更长的令牌秘密将创建更安全的签名。这个理解是否正确？

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

OAuth规范在 11.10秘密熵。

解决方案

OAuth对令牌一无所知，除了它有一个秘密与它相关联。所以你提到的所有计划都会奏效。随着网站越来越大，我们的令牌进化。以下是我们之前使用的版本，

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




2. 所以我们改变它来存储数据库中的所有东西，令牌只是一个随机数用作数据库的关键。它有一个用户名索引，所以很容易列出一个用户的所有令牌并撤销它。




3. 我们得到很少的黑客活动。随机数，我们必须去数据库才能知道令牌是否有效。所以我们再次回到加密的BLOB。这一次，令牌只包含密钥的加密值和到期。所以我们可以检测到无效或过期的令牌，而无需去数据库。

有些实现细节可能会帮助你， / p>

1. 在令牌中添加版本，以便您可以更改标记格式，而不会破坏现有版本。我们的所有令牌都有第一个字节作为版本。


2. 使用URL64安全版本的Base64对BLOB进行编码，因此您不必处理URL编码问题，这使得调试更多因为您可能会看到三重编码的基站，因此OAuth签名很困难。

I realize that the OAuth spec doesn't specify anything about the origin of the ConsumerKey, ConsumerSecret, AccessToken, RequestToken, TokenSecret, or Verifier code, but I'm curious if there are any best practices for creating significantly secure tokens (especially Token/Secret combinations).

As I see it, there are a few approaches to creating the tokens:

1. Just use random bytes, store in DB associated to consumer/user
2. Hash some user/consumer-specific data, store in DB associated to consumer/user
3. Encrypt user/consumer-specific data

Advantages to (1) is the database is the only source of the information which seems the most secure. It would be harder to run an attack against than (2) or (3).

Hashing real data (2) would allow re-generating the token from presumably already known data. Might not really provide any advantages to (1) since would need to store/lookup anyway. More CPU intensive than (1).

Encrypting real data (3) would allow decrypting to know information. This would require less storage & potentially fewer lookups than (1) & (2), but potentially less secure as well.

Are there any other approaches / advantages / disadvantages that should be considered?

EDIT: another consideration is that there MUST be some sort of random value in the Tokens as there must exist the ability to expire and reissue new tokens so it must not be only comprised of real data.

Follow On Questions:

Is there a minimum Token length to make significantly cryptographically secure? As I understand it, longer Token Secrets would create more secure signatures. Is this understanding correct?

Are there advantages to using a particular encoding over another from a hashing perspective? For instance, I see a lot of APIs using hex encodings (e.g. GUID strings). In the OAuth signing algorithm the Token is used as a string. With a hex string, the available character set would be much smaller (more predictable) than say with a Base64 encoding. It seems to me that for two strings of equal length, the one with the larger character set would have a better/wider hash distribution. This seems to me that it would would improve the security. Is this assumption correct?

The OAuth spec raises this very issue in 11.10 Entropy of Secrets.

解决方案

OAuth says nothing about token except that it has a secret associated with it. So all the schemes you mentioned would work. Our token evolved as the sites get bigger. Here are the versions we used before,

1. Our first token is an encrypted BLOB with username, token secret and expiration etc. The problem is that we can't revoke tokens without any record on host.

2. So we changed it to store everything in database and the token is simply an random number used as the key to the database. It has an username index so it's easy to list all the tokens for an user and revoke it.

3. We get quite few hacking activities. With random number, we have to go to database to know if the token is valid. So we went back to encrypted BLOB again. This time, the token only contains encrypted value of the key and expiration. So we can detect invalid or expired tokens without going to the database.

Some implementation details that may help you,

1. Add a version in the token so you can change token format without breaking existing ones. All our token has first byte as version.
2. Use URL-safe version of Base64 to encode the BLOB so you don't have to deal with the URL-encoding issues, which makes debugging more difficult with OAuth signature, because you may see triple encoded basestring.

这篇关于生成OAuth令牌的最佳做法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！