Asp.net 自动网站登录、长URL、加密

我正在建立一个安全的支付门户

我们目前有两个应用程序将使用这个。一个是web应用程序，另一个是桌面应用程序。这两种方法都需要用户登录/验证，两种应用程序都可以使用相同的凭据

我想建立一个自动登录机制，将填写所有不同的登录/订单详细信息，并能够调用上述任何一个应用程序。我一直在想，最好的方法是通过URL传递加密的信息。即

由于我们不想将支付处理过于紧密地集成到桌面应用程序中以缩小PCI范围，因此我们决定让它通过一个简单的shell来打开浏览器到一个中央的、安全的支付页面，并执行完整的URL，从而使默认浏览器打开该页面

最初我们使用AES进行加密，但目前正在重新检查，因为我们不希望向最终用户提供密钥（AES是对称的，对称加密=双方都需要私钥，既然我们要分发应用程序，为什么还要加密呢？）所以我正在考虑将其转换为使用公钥加密和.NET中内置的RSA例程

在对RSA部分进行编码后，我注意到网络上的大多数示例使用1024位作为密钥长度，我使用了这一点，现在我们的门户使用公钥加密，但是生成的URL比我使用AES时长得多，因此我开始研究URL的最大限制。表示IE是限制浏览器，路径部分大约有2048个字符。我对RSA加密的初步测试表明，我的URL长度大约为1400个字符

我的问题可以归结为：

1） 有没有更好的方法将信息从桌面应用程序传递到我没有想到的网站？我希望它能像从桌面上使用一样从另一个网页上使用，因此我现在的解决方案

2） 是否需要1024位RSA密钥？或者像这样的事太过分了？更短的密钥意味着更短的加密文本，对吗

3） 1200-1400个字符范围内的URL是否存在其他无法预料的问题？代理？防火墙？网络加速器

谢谢

2011年11月12日更新： 来看看吧，我们在这里采用的方法最近一直在折磨着我们（或者更确切地说，我们今天发现了它，尽管这个问题是一个非常零星和难以追踪的问题……）

我们加密的纯文本令牌最初相当小，只有100字节左右。这就是导致我的测试URL大约有1400字节长的原因。通过特性爬行，我们被要求向令牌添加更多数据，平均URL长度跃升到1700-1800

然而，一旦我们的纯文本长度达到173个字符及以上，URL长度再次跳跃，这次达到2080+左右，这给IE带来了问题。在对RSA加密的工作原理进行了一些调查之后，这本应该是完全可以预料到的，但最初是我的疏忽

我们使用1024位RSA加密，这意味着可以加密的最大数据块大小是1024/8-24=86字节，每86字节需要“切碎”并单独加密，所以在86*2=172时，我们只加密两个块，在上面我们加密三个、四个、五个等。通过传递172，我们的密文长度增长太长，URL现在太长了。。我可能把这里的解释弄乱了一点，但这就是它的大意

---

似乎我们将考虑设计一种更好的方法来实现这一点，因为可以预期，他们希望在未来添加“更多功能”，因此我们的令牌将变得越来越大……

假设这些都记录在数据库中，您能否使用SSL web服务来回传递数据。然后，在能够快速从桌面应用程序转到web应用程序的情况下，对网站进行rpc调用以生成随机密钥，将该密钥传递给用户并使用该密钥调用网页。使钥匙有效10秒钟，这意味着如果钥匙被捕获并损坏，它将变得无效

---

我对这类事情没有什么经验，所以我希望这一想法会有很多漏洞。

我认为后端数据库可能是一个可行的解决方案，但目前应用程序不共享中央数据库，我更愿意将访问支付门户数据库的桌面/web应用程序保持在绝对最小的水平。不过，我最终可能会选择这条路线。密钥超时是一个好主意，并且已经实现（如果他们试图在某个时间窗口之外使用加密值，网站将拒绝尝试）