我正在建立一个安全的支付门户网站。
我们目前有两个应用程序将使用它。一个是Web应用程序，另一个是桌面应用程序。这两个都要求用户登录/验证，相同的凭据可用于任一应用程序。
我想构建一个自动登录机制，它将填写所有各种登录/订单详细信息，并能够从上面提到的任一应用程序中调用它。我一直在想，最好的方法是通过URL加密这些信息。即https://mysite.com/TakePayment.aspx?id=GT2jkjh3 ....
由于我们不希望将支付处理过于紧密地集成到桌面应用程序中以减少我们的PCI范围，我们决定让它通过简单的shell执行并使用完整的URL打开浏览器到一个中央的安全支付页面导致默认浏览器打开该页面。
最初我们使用AES进行加密，但目前正在重新检查，因为我们不希望向最终用户提供密钥（AES是对称的，对称加密=双方都需要私钥，因为我们要分发应用程序，为什么还要加密呢？）所以我正在考虑将其转换为使用.NET内置RSA例程的公钥加密
在对RSA部分进行编码后，我注意到网上的大多数示例都使用了1024位的密钥长度，我使用了这个，现在让我们的门户使用公钥加密，但是生成的URL比我的时间长得多我正在使用AES，所以它让我开始研究URL的最大限制是什么。 http://www.boutell.com/newfaq/misc/urllength.html说IE是限制浏览器，路径部分大约有2048个字符。我使用RSA加密进行的初步测试显示，我的网址长度约为1400个字符。
我的问题归结为：
1）有没有更好的方法将信息从桌面应用程序传递到我不想的网站？我更喜欢从桌面使用另一个网页，因为它来自桌面，因此我目前的解决方案。
2）是否需要1024位RSA密钥？或者矫枉过正的事情？更短的密钥意味着更短的加密文本吗？
3）1200-1400字符范围内的URL是否还有其他无法预料的问题？代理？防火墙？网络加速器？
由于
更新12/11/2011： 来发现，我们最终在这里结束的方法最近在屁股上咬了我们（或者我们今天发现了它，即使问题是一个非常零星和困难的追踪...）< / p>
我们加密的纯文本令牌原本相当小，只有一百个字节左右。这导致我的测试URL长约1400字节。通过功能蠕变，我们需要向令牌添加更多数据，平均URL长度跃升至1700-1800。
一旦我们的纯文本的长度达到173个字符长，然而，URL长度再次跳跃，这次达到2080+左右，这现在导致IE出现问题。在对RSA加密如何工作进行一些调查之后，这应该是完全可以预料到的，但最初是我的疏忽。
我们使用1024位RSA加密，这意味着可加密的最大数据块大小为1024/8 - 24 = 86字节，每86个字节需要“切断”并单独加密，因此， 86 * 2 = 172，我们只加密两个块，高于我们正在加密三个，四个，五个等等。通过172，我们的密文长度增长了很长时间，URL现在太长了..我是可能在这里搞砸了一点点解释，但这是它的一般要点..
我们似乎正在考虑设计一种更好的工作方式，因为可以预期他们将来会想要“更多功能”，因此我们的代币会越来越大......
答案 0 :(得分：0)
假设这已全部记录在数据库中，您无法使用SSL Web服务来回传递数据。然后，在能够快速从桌面应用程序转到Web应用程序的情况下，对网站进行rpc调用以生成随机密钥，将其传递给用户并使用该密钥调用网页。使密钥有效10秒意味着如果一个密钥被捕获并被破坏它将变得无效？
我对这种事情没什么经验，所以我期待在这个想法中加入许多漏洞。