此身份验证/加密方案的最佳方法答案

【问题标题】：Best approach to this authentication/encryption scenario此身份验证/加密方案的最佳方法
【发布时间】：2015-11-21 14:42:38
【问题描述】：

我的场景（简化）：

为清楚起见添加： App1 是一个带有自定义 URI 的 HTML 页面。 App2 是一个基于 C# 控制台的程序

我有一个将启动另一个应用程序的应用程序。

所以我们有 App1 和 App2。

App2 无法与 App1 通信，App1 只能使用管道命令启动 App2。

我想从 App1 向 App2 发送某种身份验证字符串或哈希，App2 检查并同意它是否正确，如果正确，它将继续自行启动。

我目前脑海中的方法如下：

有一个 GUID 类型的字符串，例如{25892e17-80f6-415f-9c65-7395632f0223} 这两个程序都知道。它在 sha256 中进行散列并发送。 App2 检查哈希。并根据结果决定做什么。

根据我的阅读，SHA256 只有在他们有一个彩虹表（由字典制成）并在上面进行检查时才能及时破解。但是我肯定像上面这样的 GUID 类型字符串不会出现在所说的字典中，所以会使其足够安全吗？

这种情况下的赌注方法是什么？

【问题讨论】：

黑客可以从您的实际程序中获取 GUID。签名可能是唯一的选择。
如果我用专用程序混淆代码怎么办？
我必须同意 VoidStar 的观点，不仅因为 GUID 不够机密，还因为如果恶意程序以某种方式访问了该通信（尽管不太可能），则无法防止重放攻击。在我看来，最好的计划是给 Program1 一个公共加密密钥，给 Program2 一个匹配的私钥。让 Program1 发送其带有时间戳的通信，所有时间戳均已加密。当 Program2 收到此通信时，它可以确信这是来自 Program1 的当前通信。
您可以在两个程序之间放置一个共享密钥，该密钥将成为加密消息的一部分，以增加可信度。但主要的是，攻击者在这两个程序之间看到的任何传递都无法帮助它在以后建立自己的通信。
谢谢，我将研究这种方法

标签： c# security authentication encryption hash

【解决方案1】：

由于您提到您的应用程序可以启动子应用程序，因此您应该通过继承的句柄进行通信，以最大程度地降低与更多开放类型的 IPC 相关的风险。确保使用 未命名 对象；本地创建的管道应该没问题。您可以使用DuplicateHandle（您必须从 C# pInvoke）创建一个可继承的句柄。您可以通过任何必要的方式将句柄值传递给子进程——甚至是启动子进程的命令行，它仍然是安全的，因为句柄值对所有其他进程没有意义。

剩下的唯一问题是确保它们的二进制文件本身就是您所期望的。你应该sign your binaries with a strong name。您应该能够使用

从任何程序集中读回密钥

Assembly App2 =...
App2.GetName().GetPublicKey();

但是，设置两者以这种方式相互验证有点困难。真的有必要确保父应用程序未修改吗？如果攻击者修改了父应用程序，他们很可能无论如何都可以对您的程序做任何他们想做的事情。您可以尝试使用强命名程序集......它们使修改 App1 或 App2 变得困难，但这是一个可战胜的方案，因为攻击者基本上可以退出整个程序集。但是如果你有一个可以替换你的主应用程序的攻击者，你可能已经迷路了，所以它甚至可能不值得追求。

您应该仔细考虑攻击者是否有实际的方法来替换您的二进制文件。如果您的东西是 ACL 要求管理员权限（例如通过安装程序），那么您可能应该认为它们是安全的。没有办法保护自己免受管理员的攻击，你唯一的希望就是在这一点上混淆。

一旦您有理由确信您的二进制文件未被修改，我认为您不需要加密以在它们之间发送，只要您有一个足够安全的通道，例如这些进程本地的未命名对象。我认为一个正确未命名的管道已经足够安全，不需要加密，只要端点是合法的。不过值得第二意见。（如果你真的因为某种原因需要加密，你应该像 Diffie-Hellman 那样进行真正的密钥交换）

编辑：发现 App1 是一个 html 页面后... 一般来说，如果 App2 无法与 App1 通信，则 App2 无法保护自己免受 App1 的攻击。攻击者可以复制 App1 使用的启动命令。你被简化为混淆和希望，这并不是真正的安全。如果您正在处理敏感数据，这可能需要重新设计。我不是 HTML 方面的专家，但实际上可能可以进行双向通信。另外，请考虑远程管理会话的第三方代理。

【讨论】：

感谢您的回复，我知识渊博，我会重新研究 Diffie-Hellman，尽管它不使用盐吗？我必须让两个程序都知道？另外，您的回复很棒，但是由于我已经对场景进行了迷惑，因此我使您相信它们都是 c# 程序。我将编辑我的问题以使其清楚。但我实际上是从浏览器自定义 URI 启动 App2。
App2是个什么东西？
好的。我想了想并发布了一个编辑。基本上，在某些情况发生变化以使 App2 能够与 App1 进行通信之前，这里不可能实现真正的安全性。虽然没有详细信息，但我无法评论实际风险。
这是我的担心。我将不得不重新设计（某种程度上），因为 App 2 实际上设置了一个 websocket 服务器，我可以通过网页中的 javascript 与之通信。一切都通过 ssl 保护。但是我想看看是否可以实际验证程序的初始启动。在创建任何套接字侦听器之前。感谢您的回答

【解决方案2】：

最好的方法是保护机器本身。

运行服务器的唯一目的是运行这些应用程序。如果服务器不是多用户，则不存在恶意启动 App2 的威胁。您甚至可以设置 ACL，以便只有运行 App1 的用户帐户才具有执行和读取 App2 的权限。

如果您试图防范已获得对该服务器的远程代码执行的攻击者，那么您应该集中精力强化系统和 App1，以便在部署之前发现并修复任何漏洞。

【讨论】：