生成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签名的调试更加困难,因为您可能会看到三重编码的基本字符串.