[Mono-bugs] [Bug 75021][Maj] New - FormsAuthentication HashPasswordForStoringInConfigFile MD5 hash not always compatible to MS hash

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by barbara at idealnet.com.

http://bugzilla.ximian.com/show_bug.cgi?id=75021

--- shadow/75021	2005-05-21 15:47:36.000000000 -0400
+++ shadow/75021.tmp.29985	2005-05-21 15:47:36.000000000 -0400
@@ -0,0 +1,87 @@
+Bug#: 75021
+Product: Mono: Class Libraries
+Version: unspecified
+OS: Red Hat 9.0
+OS Details: tested on RH9, Ubuntu warty and Windows
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Major
+Component: Sys.Web
+AssignedTo: mono-bugs at ximian.com                            
+ReportedBy: barbara at idealnet.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: FormsAuthentication HashPasswordForStoringInConfigFile MD5 hash not always compatible to MS hash
+
+Description of Problem:
+the MD5 hash generated by the method HashPasswordForStoringInConfigFile of 
+FormsAuthentication is not always the same as the one created on 
+IIS/Windows, especially when special input characters were used (german 
+umlaut's and other characters, see below)
+
+Steps to reproduce the problem:
+1. create an aspx page containing a TextBox and a Button
+2. when the button is clicked, the input string from the textbox is passed 
+to the method 
+System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile
+(TextBox1.Text, "MD5");
+3. and the resulting hash code is displayed  
+
+Actual Results:
+the hash is different when using, e.g. §, or german umlaute like ä,ö,ü ....
+
+taking as example input the string "§" (just the paragraph sign) returns 
+the ff. resulting hashs:
+- on Win/IIS: BD9A4C255DEEC8944D99E01A64C1E322
+- on Mono:    D1457B72C3FB323A2671125AEF3EAB5D
+
+Expected Results:
+BD9A4C255DEEC8944D99E01A64C1E322 (that the hash is on both systems the 
+same)
+
+How often does this happen? 
+every time when special characters where used (§, ä, ö, ü --are the one 
+found until now that returned different hashs)
+
+Additional Information:
+the browser encoding was in both cases utf8. miguel said to dump the 
+string to make sure that the inputs were the same compared to IIS.
+
+Moreover, I checked the HTTP post on Windows/Linux by using ethereal on 
+the localhost. In fact, on both systems they got the same, e.g. the input 
+string 'test§' was translated in the HTTP post to "test%C2%A7" on both 
+systems. (The string was in both cases 'test§' --> and in both cases (HTTP 
+post to xsp and HTTP post to IIS) it was translated into 'test%C2%A7'.. so 
+both IIS and Mono should really get the same string as input for 
+FormsAuthentication.HashPasswordForStoringInConfigFile()
+
+Moreover, even when I tested both xsp and IIS from the same machine (from 
+ubuntu with Firefox) I get the different hash values for 'test§'.. 
+
+
+another example: 
+================
+input: ä
+
+1) on IIS: 
+hash: 8419B71C87A225A2C70B50486FBEE545
+dumped string: 
+value: 56 value: 52 value: 49 value: 57 value: 66 value: 55 value: 49 
+value: 67 value: 56 value: 55 value: 65 value: 50 value: 50 value: 53 
+value: 65 value: 50 value: 67 value: 55 value: 48 value: 66 value: 53 
+value: 48 value: 52 value: 56 value: 54 value: 70 value: 66 value: 69 
+value: 69 value: 53 value: 52 value: 53
+
+2) on Mono:
+hash: D1457B72C3FB323A2671125AEF3EAB5D
+dumped string:
+value: 68 value: 49 value: 52 value: 53 value: 55 value: 66 value: 55 
+value: 50 value: 67 value: 51 value: 70 value: 66 value: 51 value: 50 
+value: 51 value: 65 value: 50 value: 54 value: 55 value: 49 value: 49 
+value: 50 value: 53 value: 65 value: 69 value: 70 value: 51 value: 69 
+value: 65 value: 66 value: 53 value: 68
+
+See simple test case in attachment