2

I have a REST service (C#/IIS) where a small amount of data is encrypted using:

var encryptedText = MachineKey.Encode(bytes, MachineKeyProtection.All)

The encrypted string is later posted (to a REST service) and decoded using:

MachineKey.Decode(encryptedText, MachineKeyProtection.All)

The MachineKey is autogenerated, as shown in the web.config:

    <machineKey
        decryption="AES"
        decryptionKey="AutoGenerate"
        validation="AES"
        validationKey="AutoGenerate" />

After the system was upgraded from .Net 4.5.1 to 4.5.2, I can no longer decrypt a string that was encrypted before the upgrade; it gives an HttpException "Unable to validate data". (I can decrypt a string encrypted after the upgrade.)

So something changed between 4.5.1 and 4.5.2 to the algorithm making them incompatible. I haven't been able to find anything online about this specific issue. Does anyone have specific details on this issue and/or a work around to make it work?

If it matters, the project is targetting .Net 4.0, not 4.5 or 4.5.1 or 4.5.2.

(As an aside, it sounds like it is not recommended to use the MachineKey.Encode/Decode for anything other than short-term encryption, possible because of this sort of issue? Also, I know Encode/Decode are deprecated now, but I have an existing system and can't change it at this point.)

UPDATE

This is only a problem when the keys are AutoGenerate. If I give them explicit values, everything continues to work fine after the upgrade.

Frogger
  • 94
  • 8
  • It may have something to do with the way the keys are autogenerated. I just tried the same upgrade, but this time I started with explicit values for the decryptionKey and validationKey instead of AutoGenerate. It appears from initial testing that the pre-upgrade encrypted data can be decrypted after the upgrade. – Frogger Sep 08 '14 at 22:28
  • Weird. I would have advised to use hardcoded keys indeed. Could it be related to the fact that ASP.NET 4.5.2 now ignores `enableViewStateMac=false`? Check this: http://support.microsoft.com/kb/2915218 – Patrice Gahide Sep 08 '14 at 22:44
  • This scenario should still continue to work: these algorithms weren't changed after the release of 4.5. Are you certain that when the values were originally produced (during the original calls to Encode) the 4.5.1 framework was installed on the machine? Could these encrypted values have been produced much earlier - say, from 3 or 4 years ago, long before 4.5 and 4.5.1 were even released? – Levi Sep 09 '14 at 05:41
  • Thanks for the response, Levi. I can reproduce the issue 100% of the time on my test VM. The original .net framework is 4.5.1 (as determined by http://msdn.microsoft.com/en-us/library/hh925568.aspx). I generate the encrypted value. I confirm the value CAN be decrypted. I then update the .net version to 4.5.2. Perform the required reboot. After this the encrypted value cannot be decrypted (but any new value can be). My recommendation to the dev team will be to generate MachineKey keys during the install instead of using AutoGenerate. But if you want more details, let me know. – Frogger Sep 09 '14 at 15:53
  • The same issue occurs when installing .net 4.6. – Frogger Jan 06 '16 at 20:53

1 Answers1

0

One thing that I noticed is Load User Profile settings in IIS Application Pool. If you have it disabled for IIS 6 compatibility MachineKey.Decode fails to decrypt data every time app pool is recycled. For my own tests it seems like only obsolete Encode/Decode methods suffer from it and that too when using MachineKeyProtection.All. They work fine with MachineKeyProtection.Encryption.

Mazhar Qayyum
  • 630
  • 7
  • 22