11

我在这个主题中搜索了其他问题，但我没有找到答案。所以告诉我如果我错了。我是这个话题的新手，你可以很高兴地纠正我。以下是我目前的想法：

我现在在网上冲浪了 2 天，弄清楚授权网络请求的实际技术水平是什么。现在我很快发现 OAuth 2.0 似乎是最常见的标准。但是 OAuth 2.0 本身并不是标准化的。在我看来，每个更大的公司都有不同的自定义设置。但无论如何，有两种技术可以交换授权信息：Mac-Tokens 和 Bearer-Tokens。

在我看来，Mac-Tokens 提供了更多的安全性。那么为什么它没有被广泛实施呢？我能找到的唯一原因是它有点复杂。而且我多次听到不推荐使用 Mac 令牌，如果客户端不是 100% 受信任的，因为客户端必须存储秘密。但区别在哪里？无论如何，客户端必须存储授权信息。在我看来，它是不记名令牌还是 mac-secret 都没有关系。但不同的是，mac-secret（而不是 bearer-token）不是在每次请求时都通过网络提交的。

那么你能告诉我为什么不使用 mac-tokens 的合理原因吗？（除了有更多的努力）我错过了什么吗？或者我是否误解了这两种令牌技术。

感谢您的阅读和您的帮助。

4

4 回答 4

3

在我看来，答案可能很简单：承载令牌机制假设存在 SSL/TLS 层，而 MAC 令牌试图取代它。既然 SSL/TLS 被广泛接受和使用，为什么要做比需要更复杂的事情呢？

是的，正如最近在心脏出血漏洞中看到的那样，许多事情并不像预期的那样可靠，但谁保证 MAC 实现也没有故障？

正如你提到的，另一点是对称秘密的交换。在没有绝对可靠的辅助通道的情况下，这可能会很棘手。信任客户也可能是一个问题。

于 2015-12-23T11:37:02.083 回答
3

危险在于，如果客户端在不坚持 SSL/TLS 证书有效的情况下继续进行 - 这是许多客户端未能采取的步骤 - 那么不记名令牌很容易受到中间人的攻击。

Mac 令牌不易受到这种攻击；可以正确地说 Mac 令牌在没有 SSL/TLS 的情况下提供了一些真实性，或者确实在没有正确使用的情况下提供了一些真实性。

Mac 代币加强了 Bearer 代币的一个已知弱点。

不应使用共享的 MAC 密钥信任客户端。应为每个客户端生成一个新密钥。使用自己的密钥信任每个客户端，而不是使用不记名令牌信任它们，这不会带来更多的安全风险。

我认为在将授权授予交换访问令牌时会出现问题。对于 Mac 密钥，这将返回一个对称密钥。如果客户端对检查 SSL/TLS 证书马虎，那么这也容易受到 MITM 攻击。

简而言之，Mac 令牌可能不太受欢迎，因为它更复杂，但您仍然需要正确执行 SSL/TLS 以使其安全，如果您这样做，那么 Bearer 令牌也将是安全的。

于 2016-06-01T14:27:21.500 回答
1

如果正确使用 SSL/TLS 并且以机密和自助方式发出的客户端凭据，则采用 MAC 而不是承载令牌没有太多优势。只会增加复杂性。客户有责任维护 client_secret 的机密性。当然，有些客户更喜欢使用 MAC 思维来提高安全性。

于 2017-02-08T15:02:58.420 回答
0

使用 mac 身份验证，您可以将 mac 机密存储在 Android 设备或 tpm pc 设备的安全存储中……这样您就无法检索机密，但您可以在不知道机密的情况下从该商店进行 hmac 挑战。 .. 对于 tls 证书客户端，您必须将证书发送到服务器并且可以被拦截（使用 mitm）...

于 2019-12-10T18:43:55.247 回答