ASP。NET FormsAuthentication——要解密的数据的长度是无效的

时间:2021-09-06 18:30:28

We're using the FormsAuthentication class to pass encrypted tokens between a Classic ASP system and a .NET system. We have a COM component (.NET 2) called by the Classic ASP system, and the same class used directly in .NET.

我们使用FormsAuthentication类在经典的ASP系统和。net系统之间传递加密的令牌。我们有一个COM组件。NET 2)由经典的ASP系统调用,与。NET中直接使用的类相同。

The code looks something like this (without the hard-coded values):

代码是这样的(没有硬编码值):

FormsAuthentication.Initialize();
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1, "", new DateTime(2011, 1, 1), new DateTime(2012, 1, 1), false, "TEST");
var token = FormsAuthentication.Encrypt(ticket);

To decrypt, we do this:

为了解密,我们这样做:

var data = FormsAuthentication.Decrypt("E03519434CB6C157C24B5A1BFE3964537D9B0(SNIP)").UserData;

Both parts are currently running on the same server, however we have a machineKey set from when these systems were on different servers. Everything is running in .NET 3.5/CLR 2.

这两个部分目前都运行在同一个服务器上,但是我们有一个从这些系统在不同服务器上时开始的machineKey集。一切都在。net 3.5/CLR 2中运行。

Recently we've been upgrading the .NET part of the system to .NET 4. Locally, the Classic ASP stuff runs on another server, so again, we've had the same machineKey set on our local machines (.NET) and the server running the Classic ASP stuff. The same machineKey is set in both 32+64 bit v2 machine.configs and both 32+64 bit v4 machine.config (note: we run IIS in 32 bit mode for some legacy COM components).

最近我们将系统的。net部分升级到。net 4。在本地,经典的ASP在另一个服务器上运行,因此,我们在本地机器(. net)上有相同的machineKey集,服务器运行经典的ASP。在32+64位v2机器中都设置了相同的machineKey。配置和32+64位v4机器。配置(注意:我们在一些遗留COM组件的32位模式下运行IIS)。

Locally, we've had no issues at all with the tokens being generated on the Classic ASP system (COM component, running in CLR 2) working on our local machines (.NET 4). However, when we just started to roll this out to the staging server, we're getting the following error:

在本地,对于在经典的ASP系统(COM组件,在CLR 2中运行)上生成的令牌,我们完全没有任何问题。但是,当我们刚开始向staging服务器推出它时,我们会得到以下错误:

System.Security.Cryptography.CryptographicException: Length of the data to decrypt is invalid.
at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Boolean useValidationSymAlgo, Boolean useLegacyMode, IVType ivType)
at System.Web.Security.FormsAuthentication.Decrypt(String encryptedTicket)
at NewMind.Tourism.DMS.Sso2.Sso.GetUserData(String dmsId, String token) in c:\CI\W\DMS-2.4-Release\NewMind.Tourism.DMS.Sso2\Sso.cs:line 131
at NewMind.Tourism.Core.Utils.SsoUtil.GetUserData(String token) in c:\CI\W\DMS-2.4-Release\NewMind.Tourism.Core\Utils\SsoUtil.cs:line 37
at NewMind.Tourism.Core.AuthenticationService.DoSsoLogin(String ssoToken, Action successAction, Action failureAction) in c:\CI\W\DMS-2.4-Release\NewMind.Tourism.Core\AuthenticationService.cs:line 126

I've spent all afternoon trying to track down the cause. I found a lot of articles talking about "aspnet:UseLegacyEncryption" which seems to fix the issue for many, however this doesn't seem to make any difference for us. I've created a small test script that tries to decrypt two tokens generated on my local machine (one in .NET 2, one in .NET 4), and run it in both CLRs on both machines:

我花了整个下午试图找出原因。我发现很多文章都在谈论“aspnet:UseLegacyEncryption”,这似乎解决了很多问题,但是这似乎对我们没有任何影响。我创建了一个小测试脚本,试图解密本地机器上生成的两个令牌(一个在。net 2中,一个在。net 4中),并在两台机器上的两个CLRs中运行它:

  • On my machine, CLR 2 ** Works **
  • 在我的机器上,CLR 2 **工作**
  • On my machine, CLR 4 ** Works **
  • 在我的机器上,CLR 4 ** *工作**
  • Stage sever, CLR 2 ** Works **
  • 舞台服务器,CLR 2 **作品**。
  • Stage sever, CLR 4 ** Error **
  • 阶段服务器,CLR 4 **错误**
  • Stage sever, CLR 4, aspnet:UseLegacyEncryption=true ** Error **
  • 阶段服务器,clr4, aspnet:UseLegacyEncryption=true * Error ** **

I've run out of ideas. I'm not really sure what to try. The machineKeys are all identical, I've triple-checked. The UserLegacyEncryption option doesn't seem to make a difference. I can't compare tokens generated on each machine/CLR because they're different each time. We have no idea why the exact same code works on the exact same version of the .NET framework on our dev machines.

我的想法都用完了。我真不知道该试试什么。机关枪都是一样的,我检查了三遍。UserLegacyEncryption选项似乎不起作用。我不能比较每台机器/CLR上生成的令牌,因为它们每次都不同。我们不知道为什么相同的代码在我们的开发机器上的。net框架的相同版本上工作。

Our backup plans are to create a CLR 4 version of the COM component, or change the encryption entirely, but we'd really like to just understand the issue and be able to fix it.

我们的备份计划是创建一个clr4版本的COM组件,或者完全更改加密,但是我们真的希望了解这个问题并能够修复它。

1 个解决方案

#1


3  

Turned out we were missing a patch. The server was usually fully-patched, but since .NET 4 was only recently installed, and hadn't been patched afterwards, we were missing the patch that changed the encryption (due to an ASP.NET exploit).

原来我们漏掉了一个补丁。服务器通常是完全修补的,但是由于。net 4是最近才安装的,之后也没有修补过,我们丢失了修改加密的补丁(由于ASP)。净利用)。

Thanks to Damian Edwards + levib @ MS for their assistance!

感谢Damian Edwards + levib @ MS的帮助!

#1


3  

Turned out we were missing a patch. The server was usually fully-patched, but since .NET 4 was only recently installed, and hadn't been patched afterwards, we were missing the patch that changed the encryption (due to an ASP.NET exploit).

原来我们漏掉了一个补丁。服务器通常是完全修补的,但是由于。net 4是最近才安装的,之后也没有修补过,我们丢失了修改加密的补丁(由于ASP)。净利用)。

Thanks to Damian Edwards + levib @ MS for their assistance!

感谢Damian Edwards + levib @ MS的帮助!