In short: code in the digest authentication area blows up when under heavy load.

Testing out my app which uses web service to make a large number of requests (it gets through about 10 requests per second solidly over several minutes), it was ok with just one client device, but when running multiple clients simultaneously, I would - guaranteed - see "Internal Server Error" (http status 500).

Using IIS7 request tracing got the following as the culprit:

[CryptographicException: Hash not valid for use in specified state.] 
  System.Security.Cryptography.CryptographicException.ThrowCryptographicException(Int32 hr) +41 
  System.Security.Cryptography.Utils.HashData(SafeHashHandle hHash, Byte[] data, Int32 cbData, Int32 ibStart, Int32 cbSize) +0 
  System.Security.Cryptography.Utils.HashData(SafeHashHandle hHash, Byte[] data, Int32 ibStart, Int32 cbSize) +57 
  System.Security.Cryptography.HashAlgorithm.ComputeHash(Byte[] buffer) +51 
  DotNetNuke.Web.Services.DigestAuthentication.CreateMd5HashBinHex(String val) +106 
  DotNetNuke.Web.Services.DigestAuthentication.GenerateUnhashedDigest() +156 
  DotNetNuke.Web.Services.DigestAuthentication.AuthenticateRequest() +158 
  DotNetNuke.Web.Services.DigestAuthenticatorImpl.TryToAuthenticate(HttpContextBase context, Int32 portalId) +206 
  DotNetNuke.Web.Services.DnnController.AuthenticateRequest(HttpContextBase context, Int32 portalId) +145 
  DotNetNuke.Web.Services.DnnController.Initialize(RequestContext requestContext) +183 
  System.Web.Mvc.ControllerBase.Execute(RequestContext requestContext) +56 
       System.Web.Mvc.<>c__DisplayClass8.<BeginProcessRequest>b__4() +58 
           System.Web.Mvc.Async.<>c__DisplayClass1.<MakeVoidDelegate>b__0() +20 
  System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +453 
  System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +371 

Interestingly,  I found this comment on http://code.google.com/p/jsonfx/sourc... : 
"fixing 2nd most common exception: CryptographicException "Hash not valid for use in specified state." 
- System.Security.Cryptography.MD5 must be in a critical section if accessed from multiple threads"

And lo and behold, here is DotNetNuke.Web\Services\DigestAuthentication.cs : 

private static string CreateMd5HashBinHex(string val) 
{ 
 byte[] bha1 = Md5.ComputeHash(Encoding.Default.GetBytes(val)); 
 .... etc... 
} 

Funnily enough, the JsonFx.NET formerly looked like this: 

byte[] hash = MD5HashProvider.ComputeHash(value); 

and the fix was to replace with:

byte[] hash;
lock( MD5HashProvider) 
 { 
     hash = MD5HashProvider.ComputeHash(value); 
 } 

Looks pretty similar to me.  And this is happening under high load when quite likely two requests might be trying to authenticate at the same time, so makes absolute sense.

Incidentally the client software is in Java using Apache HttpClient (Seen from Android 3.2 and 4.1, I think the Android 4.0 tablet just got lucky so far).  That's a solid toolkit with a good reputation.

I suspect my recourse may be to compile my own DNN, which does not please me in the slightest!  I'm posting this in advance of going down that path, so although this is a likely fix, it does need testing.

Probably fix is of course to do:

lock(Md5) {  bha1 = Md5.ComputeHash(Encoding.Default.GetBytes(val));  };

Any comments gratefully received.

I don't know if this will affect DNN7 or not: maybe in backward compatibility areas. Sorry, I do not have time to look into that aspect, this will need to go in production using 6.2.something.

Walter Nicholls
Cornerstone Software Ltd

Since this problem only occurs during authentication, I've managed to allieviate it a bit by making the Android app authenticate less often.  Now it will only hit if two devices start a process at the same time .. much less likely.  I set three devices going at once, as best I could, and no 500 errors this time.

So at this stage I'm not going to patch DNN 6.2, and it could probably go into production with this.  Upgrading to 7.0 is not an option I suspect - much as I have been looking forward to 7.0 and Webapi for a while.  The bug is still logged in our tracker so it may get revived.