生成 OAuth 令牌的最佳实践? [英] Best practices around generating OAuth tokens?

问题描述

我意识到 OAuth 规范 没有指定任何关于ConsumerKey、ConsumerSecret、AccessToken、RequestToken、TokenSecret 或 Verifier 代码的来源，但我很好奇是否有任何最佳做法来创建非常安全的令牌(尤其是令牌/秘密组合).

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. 只需使用随机字节，存储在与消费者/用户关联的数据库中
2. 散列一些用户/消费者特定的数据，存储在与消费者/用户关联的数据库中
3. 加密用户/消费者特定数据

(1) 的优点是数据库是唯一看起来最安全的信息来源.攻击比 (2) 或 (3) 更难.

Advantages to (1) are 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).

散列真实数据 (2) 将允许从可能已知的数据重新生成令牌.可能不会真正为 (1) 提供任何优势，因为无论如何都需要存储/查找.比 (1) 占用更多 CPU.

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).

加密真实数据 (3) 将允许解密以了解信息.这将需要更少的存储空间.可能比 (1) & 更少的查找(2)，但也可能不太安全.

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?

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

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.

关注问题:

是否有最小令牌长度来确保密码安全?据我了解，更长的令牌秘密会创建更安全的签名.这种理解正确吗?

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?

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

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 improve the security. Is this assumption correct?

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

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

推荐答案

OAuth 没有说明令牌，只是它有一个与之关联的秘密.所以你提到的所有方案都会起作用.我们的代币随着网站变大而发展.这是我们之前使用的版本，

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. 我们的第一个令牌是一个加密的 BLOB，带有用户名、令牌秘密和过期时间等.问题是我们无法在没有主机上的任何记录的情况下撤销令牌.

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.

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

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.

我们很少有黑客活动.对于随机数，我们必须去数据库才能知道令牌是否有效.所以我们又回到了加密的 BLOB.这一次，令牌只包含密钥和到期的加密值.因此，我们无需访问数据库即可检测无效或过期的令牌.

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

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