3

第一种情况需要为每次通信生成一个 HMAC 来标识请求，因此服务器可以重新生成它以确保客户端被授权（因为 HMAC 是用只有服务器知道的私钥加密的，并且客户端），而第二个只需要服务颁发证书（或令牌）一次，并保持几分钟-例如。15分钟-。当然，为了防止 MITM 或 Replay 攻击，它必须仅通过 SSL 发送，并具有所有后果（更多带宽和更多 CPU 要求）。

就我个人而言，我发现第一个不仅更简单而且更强大，因为每个请求都有自己独特的数据，而第二个依赖于 SSL 证书的完整性（我并不是说这很容易破解签名的 SSL 证书，但是如果有人会破坏它，所有通信都将被嗅探）。

所以我发现他们有以下优点/缺点：

  • HMAC 优点：每个请求的唯一令牌，可以真正安全地抵御 MITM 和重放攻击 - 通过使用唯一数据组成签名和时间戳 - 易于实现
  • HMAC 缺点：要求服务器为每个单独的请求工作以重新生成令牌
  • Token pro：一个令牌用于多个请求，对需要多个客户端操作的服务很有用
  • 令牌缺点：所有通信都需要 SSL。

我想我需要设置一些测试来获得最终答案，但我很想听听有人是否已经有了一些知识或基于旧经验的一些技巧。

4

2 回答 2

0

HMAC 和 PKI 旨在解决非常不同的问题。

如果您试图保护消息在传输过程中不被修改，那么 HMAC 旨在解决该问题，并将为您提供良好的服务。

如果您试图阻止消息在传输过程中被读取，那么您唯一的选择是 PKI（例如 SSL）。虽然 PKI 提供了比 HMAC 更严格的保证——毕竟，如果一个人无法阅读该消息，则很难对该消息进行有意义的修改 :)

如果您通过 PKI 传输 HMAC 使用的密钥，请注意 HMAC 不可能比 PKI 系统更安全。毕竟，如果你破解了 PKI，那么你就可以读取 HMAC 机密。

SSL 的大部分带宽开销都将出现在握手过程中；如果您要通过 SSL 发送任何内容，那么没有理由不通过 SSL 发送其余的通信。

于 2012-10-16T04:39:50.173 回答
0

如果您只想通过 HTTP 对客户端进行基于密码（或基于密钥）的身份验证，则 HMAC 是更好的解决方案。在密码分析方面，现代 HMAC 比公钥算法更可靠。

在服务器端生成随机令牌的开销比执行公钥转换要少。

PS如果问题可以用对称密码学来解决，最好用对称密码学来解决。

于 2012-10-16T05:35:56.400 回答