这是一种常见且备受推崇的模式吗?
次要问题:我的上下文的最佳加密标准?
上下文:我有一个Windows服务,它将JSON数据发送到RESTFul服务。因为JSON Payload是身份验证凭据(passhash和用户名),但我仍然必须考虑注册用户篡改有效负载的其他“数据驱动”部分。
我的解决方案:使用源代码中的私钥/主密钥加密有效负载,尽我所能地进行模糊处理。这将验证客户端(除非主密钥被破坏)。
编辑:我的服务收集互联网延迟数据。我不想收集手工编辑的数据值。我意识到,随着网络性能/延迟的不稳定性/不断变化的特性,用户可以简单地拔掉他们的连接或掩盖他们的连接,直到我的客户端没有足够的带宽/资源来完成它的工作。这些是我无法用我的知识和时间来实际解释的事情。但是,我认为我可以保护服务免于接收手工编辑的有效负载。
答案 0 :(得分:1)
如果RESTFul服务是您自己的,您可以在其上启用Windows身份验证(或使用Windows身份验证部署其另一个实例),然后对用户进行身份验证,最好是他们属于某个角色(或组)。这样你就没有证书或密钥可以搞定,而且它是安全的。
答案 1 :(得分:1)
我想做的第一件事就是澄清你的期望。
数据有两个方面对您很重要:
完整性问题更容易解决,只需让您的程序使用与服务器的SSL连接即可。您甚至不需要使用由正常CA之一签名的证书,事实上您可能更好!您可以为您的应用程序创建一个CA,然后自己签署将在具有该私有CA的Web服务器上运行的证书。如果这样做,您可以将CA的公钥硬编码到程序中,并且只允许它连接到具有由您的私有CA签名的证书的服务器。这样做有助于防止有人设置MITM SSL代理(例如Fiddler)来编辑数据。
身份验证是一个难以解决的问题。您需要防止虚假客户端或修改后的真实客户端连接到您的服务器并发送虚假数据,这不是一个容易解决的问题。如果您的软件在 攻击者 可以运行任意代码的设备上运行,则问题无法解决。用户无法连接调试器并逐步执行代码并复制流程的原因。 “解决”它的唯一方法是在不允许用户运行任何东西的情况下运行程序,任何运行的软件必须首先由第三方审查(如非越狱手机)。
然而,你可以“缓解”这个问题,你不需要让它变得不可能,只要有足够的力量让任何恶意用户都觉得不值得努力克服你所遇到的障碍。
你可以采取一些措施使攻击者更难:
还有很多事情可以做,但这就是我想到几分钟时想出来的。
因此,如果你不太关心,只需使用沼泽标准SSL,这可能会阻止75%的篡改。如果您更关心,使用自定义CA技巧来阻止任何SSL MITM攻击,可能会使您高达80%。但是,如果你想要超过80%,那么它就会越来越难以做到,而且在某些时候你需要停下来问自己“ 我投入的时间/精力/金钱是多少阻止那一个人向我发送那些糟糕的数据值得吗?或者我可以忍住100个人中的20个向我发送不良数据,10,5,1? “