在处理基于 oData 的应用程序（ADO.NET 数据服务）或以其他方式向客户端发布 PrimaryKey 或 ForeignKey 的应用程序时......
有人可以向我解释当数据库密钥到达浏览器时加密数据库密钥的好处吗？
你将如何加密这个密钥？您将使用哪些方法进行验证？
理想情况下，这种回应的措辞可以让 PM 或高管了解这种做法的好处/缺点。
更多信息
如果您不熟悉 Web 编程，我所说的是通常隐藏的主密钥，它被发送到客户端（Web 浏览器、胖客户端或其他）并在 HTTPS 隧道的远程端解密。论点是在发送到客户端时加密和混淆主密钥（或 fk）更安全。
更新
虽然我本身没有找到任何正式的研究，但我做了一个概念验证网站，适用于多租户网站，或者目标行的服务器端验证不足。我确定这是一个安全问题，但对于这个 IT 安全论坛来说，它在本质上可能过于程序化......
我同意 AviD 在评论中所说的话。
对于最初的问题，我认为加密应用程序公开的密钥值没有好处。对我来说，这听起来像是一种奇怪的（而且从性能的角度来看很昂贵）的隐蔽安全形式。
非机密数据的安全性和完整性应由可靠的应用程序逻辑提供。IE，当前用户是否有权修改他们尝试更改的数据？或者，当前用户是否有权将学生添加到该课程，并且该课程是否仍然开放注册？
加密密钥并不能解决这些问题，但实际上，可能会导致其他问题，例如，如果将带有有效加密参数的链接通过电子邮件发送给不应访问它的人怎么办？
对于另一个示例，电子邮件密码重置，我很难理解为什么加密密钥比 GUID 具有任何显着优势，不会被加密和解密操作的性能影响所抵消。
当然只是我的两美分，但我真的看不到太多，如果有任何安全优势的话。我认为这只是额外的成本，并没有真正的好处，因为大多数（如果不是全部）潜在的安全问题将仍然存在，并且无论如何都必须以另一种方式解决。
我希望这有帮助，
-山德
这是一个场景。
Fred 想要侵入 Barney 的 MyFaceIt 帐户。他请求为自己的帐户重置密码，并收到一封带有链接的电子邮件。https://MyFaceIt.com?reset=Fred&resetid=1234
然后，他请求重置 Barney 帐户的密码。他不会看到电子邮件，但他可以猜测resetid 将是1235 或1236 或附近。
在这种情况下，您可能会为 resetid 使用 GUID 而不是按顺序生成的密钥。但是 GUID 有一些缺点（大小、索引分布......），因此您可以使用常规的顺序 id 并对值进行哈希/加密。这样你的链接就变成了https://MyFaceIt.com?reset=Fred&resetid=6FFB262274EC4B50A6320CFF15763C24 它甚至可能是 https://MyFaceIt.com?reset=F6E6B9B65D7B4ED48F1B68&resetid=6FFB262274EC4B50A6320CFF15
这使得 Fred 更难猜测 Barney 帐户的重置链接。