One of the things I've recently been working on is a solution to allow both a .NET application and a legacy VBScript / Classic ASP to be able to validate a specific username / password combination, comparing two hashed passwords. In the process, I discovered (with the help of Google and StackOverflow) that accessing .NET objects from Classic ASP isn't really all that hard! But to the issue at hand: Password Hashing! Sorting this out from the .NET side was relatively easy. For the purpose of this post, here is roughly what I have at the moment.
/// point if you don't know which to use).
/// along with the hashedPassword generated by this function.
/// same end string will be churned out the other end of this sausage machine.
Abandon my choice of SHA512 and go with MD5 where there seemed to be a bit more usage in the community. I was reluctant to do this because it isn't as good as SHA512.
Copy some code sample that has been created by someone else, that I either have to accept is OK, or spend a good deal of time understanding it and breaking it down bit by bit.
Create a custom COM object in .NET, register it in the GAC and reference that via Classic ASP.
Access the .NET functions directly from Classic ASP.
The last option won - because it worked, and because it meant a lot less maintenance and praying for things to keep working. This is the code that pretty much does the same as the above .NET code, but in VBScript.
Const strSiteWideSalt = "THIS IS A SITE WIDE SALT, BUT COULD BE A GUID"
As you can see in the VBScript example, I can create the .NET objects as I would any other type of object in VBScript, the difference comes in how I use them. Normally, in C#, you'd simply use ComputeHash() and there would be a number of overloads for you to choose from. As VBScript doesn't have the concept of overloading, you have to use a crazy-mad way of accessing the specific overload you want - using an underscore. I've not really come up with a full-proof way of working out which is which (though, if I'm honest, I didn't try much). I did however find out that they started ComputeHash(), ComputeHash_1() and ComputeHash_2() - I assume the numbers resemble the order they appear in Visual Studio when using intellisense for C# - but trial and error is normally good enough.