Question

I have an ASP.NET system with a structure like this, hosting both .Net 1.1 and .Net 2.0 apps on the same server:

/apps11/app1
/apps11/app2
/apps11/web.config
/apps20/app3
/apps20/app4
/apps20/web.config

These above two web.config files have sections specific to their version of .Net, but the parts that relate to forms authentication and machine key were identical (so that the forms authentication cookie could be shared between apps on different versions). The section is shown below (with real key obfuscated but exact length and settings preserved):

<machineKey
   validationKey="AAAABBBBCCCCDDDDEEEEFFFF0000111122223333"
   decryptionKey="BBBB9999AAAA1111"
   validation="SHA1">
</machineKey>
<authentication mode="Forms">
  <forms name=".ASPXAUTH" protection="All" timeout="15" path="/" loginUrl="/apps20/login.aspx"></forms>
</authentication>

After an upgrade of the login page component of the app, the shared authentication stopped working for the 1.1 apps. I could log in to the 2.0 apps but when I navigated to a 1.1 app it would continually redirect me back to the login page. Went through the following troubleshooting steps:

1. An issue with MS10-070 and needing the KB243375 patch? It had already been applied on the server.
2. Machinekey broken by the installer? I checked the machinekey values and the installer had updated the validationKey and encryptionKey values. However, the settings remained the same (validation=”SHA1″) and the same machinekey was in both web.config files.
3. Some other value in machine.config or web.config for each .Net Framework version? Found a domain setting in the .Net 2.0 web.config, but that seemed to only impact the domain of the ticket cookie, not the content of it.
4. Problem with encryption settings between 1.1 and 2.0 as described in How To Share Authentication Cookies across ASP.NET V1.1 and ASP.NET V2.0 Applications? Nothing had changed except the key values, so why would it break now?

Answer 1

Answering my own question. This many years after .Net 1.1, I doubt many other people will need this info, but putting it out here just in case…

In the end, the problem was indeed #4 above. Not only the keys had changed, but also the length of the keys:

<machineKey
  validationKey="EEEEEEEE77778888999900001111AAAABBBBCCCCDDDDFFFFAAAABBBBCCCCDDDDEEEEFFFF1111222233334444555566667777888899990000AAAABBBBCCCCDDDD"
  decryptionKey="888899990000111122223333444455556666777788889999" validation="SHA1">
</machineKey>

The clue came in this Security via in ASP.NET 2.0 article, which says “The decryption attribute is a new addition in ASP.NET 2.0 to reduce the overloading of the older version of the validation attribute. The Auto option for this attribute uses an algorithm that is inferred from the key size. Triple DES encryption is the default, but a key of 128 or 256 bits will use AES.”

Adding encryption=”3DES” to my machineKey tag in the .Net 2.0 web.config solved the issue. It worked for years because the old key was short enough that it inferred 3DES. The new key was long enough that it inferred AES.

I went back and read the MSDN documentation for the machineKey element. It simply says “ASP.NET determines which decryption algorithm to use, based on configuration settings”. And while later in the topic it tells you what length of key to use for each encryption type, it doesn’t say that the encryption type is inferred from the length. In fact, it tells you how to use a shorter key than the recommended length (not sure why you’d want to).

Any better solutions to this? Am I the only one who thinks the MSDN doc is somewhat lacking on this point?