Hashed and Salt with CAPICOM ? SHA 512 using asp-classic

Question

I would like to know if this method is safe to use for login since this is the only one I found that is easy to understand and that it is in asp-classic so that I a noob can understand and add to the site I have.

Thanks

    <%
    Dim sDigest,sPassword,sSalt
    sDigest=SHA256(sRndStr)


    sPassword = Request.Form("pass")
    sSalt = Request.Form("username") & "SomeThingThatisStatic1234567890"

    With CreateObject("CAPICOM.HashedData") 
      .Algorithm = 6 '<--- This will use SHA-512
      'CAPICOM_HASH_ALGORITHM_SHA1      = 0 
      'CAPICOM_HASH_ALGORITHM_MD2       = 1 
      'CAPICOM_HASH_ALGORITHM_MD4       = 2 
      'CAPICOM_HASH_ALGORITHM_MD5       = 3 
      'CAPICOM_HASH_ALGORITHM_SHA_256   = 4 - Not supported on Windows XP or 2000 
      'CAPICOM_HASH_ALGORITHM_SHA_384   = 5 - Not supported on Windows XP or 2000 
      'CAPICOM_HASH_ALGORITHM_SHA_512   = 6 - Not supported on Windows XP or 2000 

      .Hash sPassword & sSalt 

'Response.Write "Here is your hash: " & .Value 
'---> here i would then check this hash with the hash in the database
'---> and if it's the same let the user login if not go to error: wrong info.
    End With 
%>

Answer 1

Unless I've missed something fairly crucial, it doesn't look particularly safe. In particular, it looks like you're sending the hash of the salt/password over the connection, and verifying that on the server. If so, it's open to a replay attack -- i.e., somebody taps into the conversation, sees what the user responded with to log in, and then logs in under those credentials by sending the same responses. Hashing/salting the password prevents them from knowing the user's original password, but they don't care -- the know the hash, and that's all the server checks to let them log on.

To avoid that, you usually want to use a challenge/response setup:

1. The user sends something to say they want to log in
2. The server generates a random number and sends it to the user
3. The client encrypts the random number using their hashed/salted password as the key, and sends the result back to the server along with their user name
4. The server does the same encryption with its idea of that user's hashed/salted password
5. The server compares the two encrypted numbers

Each time a user tries to log in, the server generates a new/different random number. Even if somebody has the packets from an earlier login, they won't let the spy log in again.