使用主密钥通过加密进行客户端身份验证? [英] Client Authentication through Encryption using a master key?

查看:201
本文介绍了使用主密钥通过加密进行客户端身份验证?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这是一个普遍而且很受欢迎的模式吗?



次要问题:我的上下文的最佳加密标准?



上下文:我有一个Windows服务发送JSON数据到RESTFul服务。因为JSON有效载荷是身份验证凭证(passhash和用户名),但我仍然必须考虑一个注册用户篡改其他数据驱动部分的有效负载。



我的解决方案:使用源代码中的私钥/主密钥加密有效负载,最大限度地模糊。这将验证客户端(除非主密钥已损坏)。



编辑:我的服务收集互联网延迟数据。我不想收集手工编辑的数据值。我意识到,随着网络性能/延迟的不稳定/不断变化的性质,用户可以简单地拔掉他们的连接或掩体,使我的客户端没有足够的带宽/资源来完成工作。这些是我无法用现实知识和时间来解释的事情。不过,我认为我可以保护服务免受手工编辑的有效载荷。

解决方案

我想做的第一件事是澄清你的期望。



数据有两个方面对您很重要:




  • 身份验证 - 发送给您的人已从授权的未修改程序发送

  • 诚信 - 发送给您的数据在传输过程中未被修改。



完整性问题是更容易解决的问题,只需让程序使用SSL连接到服务器即可。你甚至不需要使用正常的CA之一签名的证书,实际上可能会更好,你不要!您可以为您的应用程序创建一个CA,然后自己签署将使用该私有CA在网络服务器上运行的证书。如果这样做,您可以将CA的公共密钥硬编码到程序中,并且只允许它连接到由您的私有CA签署的证书的服务器。这样做有助于防止有人设置MITM SSL代理(例如 Fiddler )在传输数据时编辑数据。



认证是一个更难解决的问题。您需要防止假客户端或修改的真实客户端连接到您的服务器并发送假数据,这不是一个容易解决的问题。如果您的软件在 攻击者 可以运行任意代码的设备上运行,问题是无法解决。不可能的原因是用户可以附加一个调试器,并逐步执行代码,并复制您的过程。 解决的唯一方法是运行您的程序,不允许用户运行任何内容,任何运行的软件必须先由第三方审核(如未越狱的手机)。



但是,您可以减轻问题,您不需要使其不可能,只是足够让任何恶意用户找不到值得克服的努力你所在的障碍。



有些事情可以让攻击者更难:




  • 所有消息均使用您最擅自隐藏的秘密密钥进行签名。

  • 在代码上使用代码混淆器,使其难以逆向工程。 li>
  • 在您的SSL连接中使用客户端证书,并让您的服务器拒绝任何没有连接的连接。

  • 更高一位比您更有经验的顾问使您的代码更难以逆向工程。



还有更多的可以做,但这是我想出的只是想要几分钟。



所以要把这一切全部下来,如果你不太关心,只要使用沼泽标准的SSL,这可能会阻止75%的笨蛋环。如果您更加关心,请使用自定义CA技巧来抵制任何SSL MITM攻击,以达到最高80%的目标。但是,如果你想达到80%以上,就会变得更加难以做到,在某些时候你需要停下来,问自己 我正在投入的时间/精力/金钱阻止那个更多的人发送给我不好的数据值得吗?或者我可以跟100个人中的20个发送我不好的数据,10点,5点,1点呢? p>

Is this a common and well-regarded pattern?

Secondary Question: Best encryption standard for my context?

Context: I have a windows service which sends JSON data to a RESTFul Service. In that JSON Payload is authentication credentials (passhash and username), but I still must account for a registered user tampering with the other "data driven" parts of the payload.

My Solution: Encrypt the payload with a private/master key from within the source code, obfuscated the best I can. This will verify the client (unless the master key is broken).

EDIT: My service collects internet latency data. I do not want to collect hand-edited data values. I realize that with the volatile/everchanging nature of network performance/latency, a user could simply unplug their connection or bunker down theirs to the point that my client is not given enough bandwidth/resources to do it job. These are things that I cannot realistically account for with the knowledge and time that I have. However, I do think I can protect service from receiving hand-edited payloads.

解决方案

First thing I want to do is clarify something in your expectations.

There are 2 aspects to the data that are important to you:

  • Authentication - The data that was sent to you was sent from a authorized, unmodified, program
  • Integrity - The Data that was sent to you was not modified in transit.

The Integrity problem is the easier one to solve, simply have your program use a SSL connection to the server. You don't even need to use a cert signed by one of the normal CA's, in fact it may be better that you don't! You could create a CA for your App, then sign the cert yourself that will be running on the webserver with that private CA. If you do that you can hard code the public key of your CA in to the program and only allow it to connect to servers who have certificates signed by your private CA. Doing this will help prevent someone setting up a MITM SSL Proxy (for example Fiddler) to edit the data while it is being transmitted.

Authentication is a bit of a harder problem to solve. You need to prevent fake clients or modified real clients from connecting to your server and sending fake data, and that is not a easy problem to solve. If your software is running on a device where the attacker can run arbitrary code, the problem is impossible to solve. The reason it is impossible is the user could attach a debugger and step through your code step by step and replicate your process. The the only way to "solve" it is running your program on something that does not allow the user to run anything and any software that does run must be vetted by a 3rd party first (like a un-jailbroken phone).

However you can "mitigate" the problem, you don't need to make it impossible, just hard enough that any malicious user would not find it worth the effort to overcome the obstacles you put in.

Some things you can do to make it harder on a an attacker:

  • All message are signed using a secret key you do your damndest to hide.
  • Use a code obfuscator on the code to make it harder to reverse engineer.
  • Use client certificates in your SSL connection and have your server reject any connection that does not have them.
  • Higher a consultant who is more experienced than you to make your code harder to reverse engineer.

There is much much more that can be done but that is what I came up with with just thinking for a few minutes.

So to boil this all down, if you are not too concerned, just use bog standard SSL, that will likely stop 75% of the tampering. If you are more concerned, use the custom CA trick to foil any SSL MITM attacks to maybe get you up to 80%. But if you want to get above that 80%, it gets exponentially harder to do, and at some point you need to stop and ask your self "Is the amount of time/effort/money I am putting in to stopping that one more person from sending me that bad data worth it? Or can I just live with 20 out of 100 people sending me bad data, what about 10, 5, 1?"

这篇关于使用主密钥通过加密进行客户端身份验证?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆