我正在尝试实现 Web 服务，并且需要一些（非常）简单的 Authenticate 来限制对服务的访问。
我发现了 HMAC，我想我了解如何实现它。但我有几个问题。
假设我在消费者端有这个 HTML 表单。向我的服务器发出 GET/POST 请求时。
public_key使用secret_key？POST变量/数组的哈希？我认为发送public_key唯一的哈希就足够了，但只是想确保并询问你们。
我打算这样做：
public_keypublic_key使用secret_key.你的意见？
澄清： public_key就像client unique id我可以用来识别secret key在服务器上生成散列的内容一样。
pubkey 只是用作识别用户的另一种方式。顺便说一下，它也可能是用户电子邮件，因为您可能不希望将用户数据暴露给他们的程序员（或潜在的嗅探器），因此您为每个用户创建一个唯一标识符。这就是它的全部意思。然后你需要一个私钥来签署你的哈希。
当然，为了让它值得，您必须签署所有唯一的请求数据，否则有人可能会更改您的请求正文，而您将无法检测到它（MITM 攻击）。
您还应该注意创建必须包含在 HMAC 本身中的时间戳，然后将其与请求一起传递。通过这种方式，您可以使签名过期，因此您不会受到重放攻击（有人窃取了请求并且不修改它就将其回复到服务器，多次执行相同的操作......如果它是一个请求为您的服务付费，您的用户会非常生您的气）。
还要记住（没有人这样做）加密 HMAC 本身内部的 Request-URI 以及 HTTP 方法（又名动词）如果您使用的是 RESTful Web 服务，否则恶意用户将能够将请求发送到其他 URI 或（使用 RESTful 服务）会改变请求的含义，因此有效的 GET 可能会变成潜在的 DELETE。一个例子可能是：用户想要查看其所有数据，发出 GET 请求，中间人读取请求并使用 DELETE 更改 GET。如果某些内容不在您可以检查的 HMAC 内，您将没有机会检测到该内容已更改，因此您会收到 DELETE 请求并发出轰隆声！您销毁所有用户数据。
所以永远记住：对你的请求至关重要的一切都必须是可验证 的如果你依赖 HMAC，那么你必须加密你需要信任请求的所有内容。
还要始终记住通过拒绝所有请求来开始设计您的系统，然后如果您可以验证它们执行请求的操作。这样，您总是会依赖被拒绝的请求。最好有一封用户电子邮件告诉您他不能做一些让您的用户数据在网络上传播的事情。
使用 TLS。它解决了这个问题以及许多您甚至还没有想到的问题。