We have a programmer who has coded himself into a corner...and the only solution appears to be a CLR routine to be able to correctly hash the password so that both ASP and ASP.Net version of the code generate the same hash so when the password is decrypted to be sent to the end user, it correctly dehashes.
Are you sure this is the way you want to go? Normally, you shouldn't be able to dehash a password and you don't want to send a decrypted password at all if you can avoid it. Traditionally, you would store the hashed value in the database and require the front end to pass the hashed value. If you can't require that of the front end you can pass a plaintext password from the front end, hash it and compare it to the stored value.
Additionally, while you didn't specify a timeframe for those 100,000 calls (x20 so 2,000,000 calls), that seems like a pretty hefty number of logins that are happening. Would it be better to store connection/permission information at the server level using some sort of permission structure and use a guid/crc32 pair at the client to identify the permission set for the connection.
As for your actual questions, I don' know.