使用通道加密 (https) 是否会使密钥散列变得多余？
我正在设计一个 Web 服务，客户端连接该服务以检索一些私人数据。每个客户端都有一个唯一的 ID 和一个密钥（由服务器生成），它们作为参数发送到 Web 服务，以便对其进行身份验证。此外，所有通信均通过 HTTPS 完成。
我还计划使用 HMAC-SHA256，以避免通过网络发送密钥。
但是，我想知道这是否是绝对必要的。既然 HTTPS 为我提供了客户端和服务器之间的安全通道，为什么我真的介意通过该通道发送密钥呢？
我设法想出的唯一原因是，不知情的开发人员可能会在将来添加服务并且不会拒绝非 HTTPS 连接，因此散列密钥是针对企业软件开发现实的一种保险，一条额外的线如果你愿意的话，可以进行防御。
我错过了更重要的事情吗？这是某些攻击媒介可以利用的真正漏洞吗？
I'm designing a web service that clients connect to in order to retrieve some private data. Each client has a unique ID and a secret key (generated by the server) that are sent as parameters to the web service in order to authenticate itself. In addition, all communications are done over HTTPS.
I'm also planning to use HMAC-SHA256, in order to avoid sending the secret key over the wire.
However, I'm wondering whether this is strictly necessary. Since HTTPS gives me a secure channel between client and server, why would I really mind sending the secret key over that channel?
The only reason I managed to come up with is that an unknowledgeable developer might add a service in the future and not reject non-HTTPS connections, so hashing the secret key is a sort of insurance against the realities of corporate software development, an extra line of defense if you will.
Am I missing something more significant? Is this a real vulnerability that some attack vector could take advantage of?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
还有其他的，但故事是这样的：SSL 很复杂，并且经常以创造性的方式受到攻击。如果您的连接是安全的，那么与人类代码的复杂性和 CPU 时间成本相比，散列几乎没有价值。但是，如果 SSL 会话遭到破坏，您仍然保存了密钥。就像我们在数据库中散列密码一样，尽管事实上没有任何不受欢迎的人应该有权访问，但在 SSL 的情况下对密钥进行散列也是明智的做法。
There are others, but the story is this: SSL is complicated and often attacked in inventive ways. If your connection is secure, then the hashing has little value compared to the complexity in code for humans and the cost in cpu time. However, if the SSL session is compromised, then you've still saved your key. Much as we hash passwords in databases despite the fact that nobody undesirable should have access, hashing your key despite SSL would be wise.
通道可能是安全的，但这并不能告诉您有关端点的任何信息：取决于相关浏览器（及其插件/扩展/...），您的密钥很可能最终保存在用户计算机上某个基于磁盘的缓存中，并且它可以永远留在那里直到结束。
这不是一个非常有趣的漏洞...直到您意识到各种恶意软件已经在磁盘中搜寻，寻找任何有价值的东西 - 并且以当前的速度，您的一些用户将被感染（除非您的网站只有二十个用户;))。
所以：不要为了节省一些 CPU 周期而放弃一个非常强大的加密机制；这是一个潜在危险的微优化 IMNSHO。
The channel may be secure, but that doesn't tell you anything about endpoints: depending on the browser in question (and its plugins/extensions/...), your key could very well end up in a disk-based cache somewhere on the user's computer, and it could sit there until the end of forever.
That is not a very interesting vulnerability ... until you realize that various malware already goes trawling through the disks, looking for anything valuable - and with the current rates, some of your users will be infected (unless your website only has twenty users ;)).
So: don't throw away a pretty powerful crypto mechanism to save a few CPU cycles; that's a potentially dangerous microoptimization IMNSHO.