locked
legacy encryption mode and Microsoft .NET Framework 1.1 RRS feed

  • Question

  • User-1206284356 posted

    We have some application developped with Visual Studio 2005 and works on multiples platformes (  Microsoft .NET Framework 1.1, Microsoft .NET Framework 2.0 and later versions).

    We are using form based authentification for each application.

    After checking this article 

    http://www.dotnet-tech.com/tutoriels/asp.net_2_secu/asp_net_2_securite.pdf

    We modified the web.config file so that form authentication work with Microsoft .NET Framework 2

    Now, and after installing MS10-070 the form authentication is no more working for Microsoft .NET Framework 1.1

    we tried to use the legacy encryption mode but it appear that this option cannot be applied  to Microsoft .NET Framework 1.1.

     

    could you please tel me how to force Microsoft .NET Framework 1.1 to use Legacy encryption mode?

     

    best regards.

     

    Tuesday, October 5, 2010 5:25 AM

Answers

  • User-318900040 posted

    I have successfully tested a workaround to this problem. (To use until Microsoft hopefully fixes the patch for 1.1)

    Summary of the workaround:

    1) Create a webservice that runs on an asp.net 1.1 host. This creates the encrypted string that goes in the cookie. to be used by the 1.1 site.
    2) The login form in the 2.0 site now creates 2 cookies. The first cookie is for the 2.0 site use, the 2nd is for the 1.1 sites. To create the 2nd cookie, call the above web service to get the encrypted string.

    See code below

    Notes on my specific situation:
    It has 2 sites that share the FormsAuthenticationTicket cookie. One site is hosted using ASP.Net 1.1 the other 2.0. The code for these is written in 1.1 and 3.5 frameworks, but that does not appear to be a factor. What matters is the IIS setup of the site itself. In my case, the FormsAuthenticationTicket cookie is encrypted and created by the site hosted by 2.0. The 1.1 site decrypts the cookie to create a FormsAuthenticationTicket.

    Code for method in the 1.1 hosted web service

    [WebMethod]
    public string EncryptedFormsAuthenticationTicket(string identityName, string userdata, string timeoutMinutes)
    {
     double doubleTimeoutMinutes = 20;
     try {doubleTimeoutMinutes = System.Convert.ToDouble(timeoutMinutes);}
     catch {doubleTimeoutMinutes = 20;}
     if (doubleTimeoutMinutes < 1) { doubleTimeoutMinutes = 20; }

     System.Web.Security.FormsAuthenticationTicket myFormsAuthenticationTicket
      = new System.Web.Security.FormsAuthenticationTicket
      (1
      ,identityName
      ,DateTime.Now
      ,DateTime.Now.AddMinutes(doubleTimeoutMinutes)
      ,false
      ,userdata
      );

     string encryptedTicket = System.Web.Security.FormsAuthentication.Encrypt(myFormsAuthenticationTicket);
     return encryptedTicket;
    }

     

    Code in the 2.0 site

    string myIdentityName = "myIdentityName";
    string myUserData = "myUserData";
    bool successStatus = My20SiteMethodToLoginCreateFormsAuthenticationAndAddCookie(myIdentityName, myUserData);
    if (successStatus)
    {
    myEncryptedTicketService.EncryptedFormsAuthenticationTicketService myInstanceOfTheService = new myEncryptedTicketService.EncryptedFormsAuthenticationTicketService();
    string my11EncryptedTicket = myInstanceOfTheService.EncryptedFormsAuthenticationTicket(myIdentityName, myUserData, "20");
    string my11CookieName = FormsAuthentication.FormsCookieName + "_11";
    HttpCookie my11Cookie = new HttpCookie(my11CookieName, my11EncryptedTicket);
    my11Cookie.Secure = FormsAuthentication.RequireSSL;
    HttpContext.Current.Response.Cookies.Add(my11Cookie);
    }

     

    One final note:
    The config entry needs to match in both sites and the web service
    <system.web> <machineKey validationKey="xxx" decryptionKey="yyy" validation="SHA1" />
    and the 2.0 site also needs to use decryption="3DES" in the same entry

     Steve

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, October 7, 2010 3:26 PM

All replies

  • User-781407700 posted

    I have the same issue as you have reported.

     


    I have an issue with my cross-framework authentication functionality since the recent updates on the Microsoft .NET Framework due to issue MS10-070 which should be resolved in OOB updates KB2416451 and KB2418241.

    When I Install the updates my authentication fails with an exception "Unable to validate data." "at System.Web.Configuration.MachineKey.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length)\r\n   at System.Web.Security.FormsAuthentication.Decrypt(String encryptedTicket)\r\n   at " - rest of stack trace.

    This error is new for me, hasn't occurred in the three years we've been using this code without a hitch.


    The formsauthentication cookie is created in .NET 2.0 code:

    /* .NET 2.0 Code: */

     // create formsauthenctication cookie. Control via configuration that 3DES is used as encryption algorithm,
      // as it is used in 1.1, and specify a validation and decryption key.
    
      // get cookie settings from config
      string logonCookieName = ConfigurationManager.AppSettings["logonCookie"];
      string logonCookieDomain = ConfigurationManager.AppSettings["logonCookieDomain"];
    
      // Create encrypted Ticket
      FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1,
          ssoId.Name, DateTime.Now, DateTime.Now.AddMinutes(30), false, String.Join("|", claimValues)); //claimValues is an array of strings used to pass claims to a .net 1.1. environment.
      string encryptedTicket = FormsAuthentication.Encrypt(ticket);
    
      // Create Cookie
      HttpCookie authCookie = new HttpCookie(logonCookieName, encryptedTicket);
      authCookie.HttpOnly = true;
      authCookie.Domain = logonCookieDomain;
    
      // add cookie to response
      Response.Cookies.Add(authCookie);
    

    /* end code */

    And it's been used in .NET 1.1 code:

    /* .NET 1.1 code: */

    HttpCookie authCookie = context.Request.Cookies[cookieName];
    
    // decrypt cookie
    FormsAuthenticationTicket authTicket = null;
    try
    {
     authTicket = FormsAuthentication.Decrypt(authCookie.Value);
    }
    catch (Exception ex)
    {
     // Exception "" is thrown when KB2416451 or KB2418241 is installed.
     return; 
    }
    


     

    /* end code */


    The machine key configuration are identical in both environments, and in de .NET 2.0 application the encryption method has been set to 3DES.
    The .NET 2.0 key is:
    <machineKey validation="SHA1" decryption="3DES" validationKey="MyVeryLongValidationKey" decryptionKey="MyVeryLongDecryptionKey" />
    The .NET 1.1 key is:
    <machineKey validation="SHA1" validationKey="MyVeryLongValidationKey" decryptionKey="MyVeryLongDecryptionKey" />

    My questions are:
    What am I missing here?
    Where does the validation error come from?
    What steps can I take to fix this issue?

     

     

    Tuesday, October 5, 2010 6:04 AM
  • User333146938 posted

    Our site has almost an identical setup, except that we are using .net framework 3.5 instead of 2.0.  

    After installing a series of .Net security updates on Oct. 3, we began getting an decryption error in our .Net 1.1 application whenever it receives a cookie from our .net 3.5 webapp.

    I found a partial solution to this issue. However it requires uninstalling .Net Framework 1.1 Security Patch (KB2416477)

    After you uninstall this patch, we just had to add the following line to web.config file in the 3.5 framework web solution to resolve the problem.

     <appSettings>

    <add key="aspnet:UseLegacyEncryption" value="true" />

    </appSettings>

    If anyone has found a more permanent solution - (you can make legacy encryption work after installing the 1.1 security patch and others), please share your solution.

    Regards,

    Beetz12

     

    Tuesday, October 5, 2010 2:28 PM
  • User-318900040 posted

    I have successfully tested a workaround to this problem. (To use until Microsoft hopefully fixes the patch for 1.1)

    Summary of the workaround:

    1) Create a webservice that runs on an asp.net 1.1 host. This creates the encrypted string that goes in the cookie. to be used by the 1.1 site.
    2) The login form in the 2.0 site now creates 2 cookies. The first cookie is for the 2.0 site use, the 2nd is for the 1.1 sites. To create the 2nd cookie, call the above web service to get the encrypted string.

    See code below

    Notes on my specific situation:
    It has 2 sites that share the FormsAuthenticationTicket cookie. One site is hosted using ASP.Net 1.1 the other 2.0. The code for these is written in 1.1 and 3.5 frameworks, but that does not appear to be a factor. What matters is the IIS setup of the site itself. In my case, the FormsAuthenticationTicket cookie is encrypted and created by the site hosted by 2.0. The 1.1 site decrypts the cookie to create a FormsAuthenticationTicket.

    Code for method in the 1.1 hosted web service

    [WebMethod]
    public string EncryptedFormsAuthenticationTicket(string identityName, string userdata, string timeoutMinutes)
    {
     double doubleTimeoutMinutes = 20;
     try {doubleTimeoutMinutes = System.Convert.ToDouble(timeoutMinutes);}
     catch {doubleTimeoutMinutes = 20;}
     if (doubleTimeoutMinutes < 1) { doubleTimeoutMinutes = 20; }

     System.Web.Security.FormsAuthenticationTicket myFormsAuthenticationTicket
      = new System.Web.Security.FormsAuthenticationTicket
      (1
      ,identityName
      ,DateTime.Now
      ,DateTime.Now.AddMinutes(doubleTimeoutMinutes)
      ,false
      ,userdata
      );

     string encryptedTicket = System.Web.Security.FormsAuthentication.Encrypt(myFormsAuthenticationTicket);
     return encryptedTicket;
    }

     

    Code in the 2.0 site

    string myIdentityName = "myIdentityName";
    string myUserData = "myUserData";
    bool successStatus = My20SiteMethodToLoginCreateFormsAuthenticationAndAddCookie(myIdentityName, myUserData);
    if (successStatus)
    {
    myEncryptedTicketService.EncryptedFormsAuthenticationTicketService myInstanceOfTheService = new myEncryptedTicketService.EncryptedFormsAuthenticationTicketService();
    string my11EncryptedTicket = myInstanceOfTheService.EncryptedFormsAuthenticationTicket(myIdentityName, myUserData, "20");
    string my11CookieName = FormsAuthentication.FormsCookieName + "_11";
    HttpCookie my11Cookie = new HttpCookie(my11CookieName, my11EncryptedTicket);
    my11Cookie.Secure = FormsAuthentication.RequireSSL;
    HttpContext.Current.Response.Cookies.Add(my11Cookie);
    }

     

    One final note:
    The config entry needs to match in both sites and the web service
    <system.web> <machineKey validationKey="xxx" decryptionKey="yyy" validation="SHA1" />
    and the 2.0 site also needs to use decryption="3DES" in the same entry

     Steve

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, October 7, 2010 3:26 PM
  • User370810054 posted

    Hi Steven,

    I've encountered the same problem you list here, though I have the reverse scenario, whereby the login is managed in the 1.1 site and decrypted in the 2.0 site (well, in 2 actually).  I would have thought that I would be able to just turn your solution on it's head so to speak, I was jsut wondering if you, or anyone else, has already had success in doing this?

    Cheers

    Richard


    Wednesday, October 13, 2010 12:08 PM
  • User-1008856481 posted

    We have the same problem with tens of application: Net1.1 app manages logon process with ticket generation and Net2/3/4 app checks the authentication ticket (obviosly on the same domain/machine and with correct machinekey settings).

    All was good before patches and now, on all development (winxp/win7) and test/staging (win2003/2008) systems (32/64bits), we have the problem described so ... we are not patching production systems!

    Removing net1.1 patch and setting aspnet:UseLegacyEncryptions "fixes" the problem BUT we need to justify to our customers this unusual methodology and make them confident about security.

    We also reproduced the problem with two simple pages (outside any other application logic) and we are in touch with microsoft support... we are waiting!

    Obvioulsy we don't like to modify and recompile and test such a lot of apps... if possible.

     

     

     

    Thursday, October 14, 2010 3:57 AM
  • User-318900040 posted

    I have not tested the reverse but I believe it would work just the same way. The solution is that 2 cookies are needed with 1 encrypted using an asp.net 1.1 service/page and the other using asp.net 2.0 service/page.

    As to the user with tens of apps, if the cookie name is stored in the config, then it would require a config change to only the portion of apps that is the smaller of the 2 groups. (asp 1.1 vs asp 2.0) If there are 50 apps, with 3 deployed on 1.1 and 47 on 2.0, then only the cookie name on the 3 apps needs to be changed. If the ratio of 1.1 to 2.0 was more even (say 25/25) then it would need to be changed on 1/2 the apps. In any case, the real work of the workaround is implemented in only the page the performs the login and leaves the cookies.

    Monday, October 18, 2010 9:53 AM
  • User-1008856481 posted

    Microsoft Support has confirmed to me the bug. They are testing the fix and probably in the next days the patch will be available to the public.

    BTW @stevemaude, yes I understand you suggestion but the problem obviously is not how difficult is or not to workaround. The problem is that our application are something like a framework and so we have to test thousound of installation at customer home where they may have done any work implementation with "that" cookie authentication. So not so simple and not so cheap.

    thank you again

     

    Monday, October 18, 2010 10:10 AM
  • User-1263781944 posted

    We are having the same issue, since the patches were installed via WSUS yesterday. We have websites running under .Net 2.0 that also use SQL Server Reporting Services (RS) 2000 - which runs under .Net 1.1 

    When we click onto a report, we now get a RS login prompt. If we login there, we see the report, but when we click back to an .aspx page running under .Net 2.0, we get another login prompt - rather than being seamlessly able to move between them.

    Scott Gu said here http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx that "Forms Authentication can continue to work across ASP.NET Versions" but only mentions framework versions 2.0 upwards, i.e. no mention of .Net 1.1. Not sure if that was an accidental omission, or whether this just won't work for .Net 1.1 too ?

    This thread states that MS Support are aware and working on a fix, so hopefully one will come along soon. As for the coding workaround posted by stevemaude, I don't think that should mark this thread as having an answer, because that implies it's been fixed by Microsoft.

    Hopefully the eventual fix from MS will be well publicised!

    Thanks in advance.

    Iain.

    Wednesday, October 20, 2010 9:54 AM
  • User-1008856481 posted

    here we are ...hot fix: http://support.microsoft.com/kb/2433751/en-us 

    we tested it in development env. and it's seems to be good.

    Remember to reset previous cookie or change the cookie name in both applications.

    Eventually remove the legacy encryption key:

    <appSettings>

    <add key="aspnet:UseLegacyEncryption" value="false" />

    </appSettings>

    bye

    Tuesday, November 2, 2010 1:29 PM
  • User124618443 posted

    Thanks for posting this solution.  I just spent the last 6 hours troubleshooting this exact issue (doing Internet Searches) but I didn't find this forum message until now.   

    Next time, I will come to this website first.

    Thursday, November 4, 2010 7:55 PM
  • User-318900040 posted

    I just successfully tested the posted hotfix so my workaround is no longer needed.

    Steve

    Friday, November 5, 2010 9:41 AM