views:

59

answers:

3

I have a RESTful API containing a URI of /UserService/Register. /UserService/Register takes an XML request such as:

<UserRegistrationRequest>
  <Password>password</Password>
  <Profile>
    <User>
      <UserName>username</UserName>
    </User>
  </Profile>
</UserRegistrationRequest>

I have the following questions given the above scenario:

  1. Is there a way (using C# and .Net 3.5+) of enforcing/validating that clients calling Register are passing a hashed password rather than plaintext? Is leaving the choice of hashing algorithm to be used to the client a good idea?

  2. We could provide a second URI of /UserService/ComputePasswordHash which the client would call before calling /UserService/Register. This has the benefit of ensuring that each password is hashed using the same algorithm. Is there a mechanism within REST to ensure that a client has called one URI before calling another?

Hope I've explained myself ok.

Many thanks in advance for any help.

A: 

It's a bad idea to let clients hash passwords themselves. Generally speaking, hashing only password is not very secure: a random salt has to be appended to the password so that same passwords will produce different hash values. With that, client will have to generate salt (preferably using cryptographically secure algorithm), compute hash of a resulting sting (using compliant implementation of a well-known hashing algorithm) and then send three pieces of information back to the server:

  • Hashing algorithm name
  • Salt
  • Hashed password

What if server doesn't have an implementation of a particular hashing algorithm? What if client hashing algorithm produces different results compared to servers' one?

Now back to your questions:

  • You can enforce password to be sent in Base64 encoding and then check if this string, converted back to byte array, contains non-printable characters, which are very likely to appear in a hash value. Though they might not be there
  • You can include some kind of token to a response from ComputePasswordHash and then require your clients to pass this token back to Register
Anton Gogolev
+3  A: 

Passing a hashed password in a REST service isn't more secure than clear password. If the password gets sniffed it doesn't matter if it's hashed or not, it can be used.

Best thing to do is hash the password on server and accept secure connections only (SSL/https)

Catalin DICU
A: 

Hashing would not be good idea . A more better would be either use SSL or use a subset of it youself using public key encryption api in .NET framework.

You will expose function GetPublicKey() which will return public key through which user will encrypt his password and send it to you. Then use your private key to decrypt it. And check if it correct. RSA or Elliptic curve base public key alogs are very good. Just use 1024bit.

UPDATE: check this example as well also this from msdn

affan