此身份验证/加密场景的最佳方法

本文关键字：最佳 方法 身份验证 加密 | 更新日期: 2023-09-27 18:10:13

我的场景(简化):

为清晰起见添加: App1是一个带有CUSTOM URI的HTML页面。App2是一个基于c#控制台的程序

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

我们有App1和App2。

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

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

我现在的想法是:

具有两个程序都知道的GUID类型sting，例如{25892e17-80f6-415f-9c65-7395632f0223}。它以sha256格式散列并发送。App2检查哈希值。并根据结果决定做什么。

从我所读到的，如果他们有一个彩虹表(从字典中制作)并检查它，SHA256只会及时被破解。然而，我肯定像上面这样的GUID类型字符串不会在说的字典中，所以会使它足够安全吗?

在这种情况下，赌注方法是什么?

此身份验证/加密场景的最佳方法

既然您提到您的应用程序可以启动子应用程序，那么您应该通过继承句柄进行通信，以尽量减少与更开放的IPC类型相关的风险。确保使用一个未命名的对象;本地创建的管道就可以了。你可以使用DuplicateHandle(你必须从c#中调用)来创建一个可继承的句柄。您可以通过任何必要的方式将句柄值传递给子进程——甚至通过命令行启动子进程，这仍然是安全的，因为句柄值对所有其他进程都是没有意义的。

唯一剩下的问题是确保它们的二进制文件本身是您所期望的。您应该使用强名称对二进制文件进行签名。您应该能够用

从任何程序集中读回键。
Assembly App2 =...
App2.GetName().GetPublicKey();

然而，设置两者以这种方式相互认证有点困难。真的有必要确保父应用程序未被修改吗?如果攻击者修改了父应用程序，他们可能会对你的程序做任何他们想做的事情。你可以尝试强命名程序集…它们使修改App1或App2变得困难，但这是一种可行的方案，因为攻击者基本上可以放弃整个程序集。但如果你有一个攻击者可以取代你的主应用，你可能已经输了，所以它可能甚至不值得追求。

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

一旦你有理由确信你的二进制文件没有被修改，我认为你不需要加密它们之间的发送，只要你有一个足够安全的通道，比如那些进程本地的未命名对象。我认为一个正确命名的管道已经足够安全，不需要加密，只要端点是合法的。不过还是值得再听听别人的意见。(如果你真的需要加密，你应该做一个真正的密钥交换，如Diffie-Hellman)

编辑:在发现App1是一个html页面后…一般来说，如果App2不能与App1通信，那么App2就没有办法保护自己不受App1的攻击。攻击者可以复制App1使用的启动命令。你会陷入困惑和希望之中，这并不是真正的安全。如果您正在处理敏感数据，这可能需要重新设计。我不是HTML方面的专家，但是双向通信实际上是可能的。另外，考虑一个远程管理会话的第三方代理。

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

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

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

相关文章：