基于HMAC over HTTP或HTTPS上的单令牌的身份验证系统是否更加昂贵？

Question

第一种情况需要为每个通信生成标识请求的HMAC，因此服务器可以重新生成它以确保客户端被授权（因为HMAC使用仅由服务器和客户端），而第二个只需要服务发出一次证书（或令牌），并保持活动几分钟-ex。 15分钟-。当然，为了防止MITM或重放攻击，它必须通过SSL发送，包含所有后果（更多带宽和更多CPU要求）。

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

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

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

我想我需要设置一些测试来获得最终答案，但我很想知道某人是否已经根据旧经验获得了一些知识或者一些经验。

Answer 1

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

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

如果您试图阻止邮件在传输中被读取，那么您唯一的选择是PKI（例如SSL）。 PKI提供了比HMAC更严格的保证 - 毕竟，如果一个人无法阅读消息，那么对该消息进行有意义的修改是非常困难的：）

如果您通过PKI传输HMAC使用的密码，请注意HMAC不可能比PKI系统更安全安全。毕竟，如果你打破PKI，你就可以阅读HMAC的秘密。

SSL的大多数带宽开销都将在握手过程中进行;如果您要通过SSL发送任何内容，则没有理由不通过SSL发送其余的通信。

Answer 2

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

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

P.S。如果问题可以通过对称密码术来解决，那么最好用对称密码学来解决它们。