How to secure HTTP JSON web service in .NET WCF

Question

So, I want to protect the json http web service.

I will have many system users, all of whom will have a username and password. I want to store a randomly collected hash of user passwords in my database in order to avoid detection of all passwords in case of hacking the database and salt (for each password), to avoid pre-computed rainbow tables and dictionary attacks.

I am looking at digest authentication, as it has the advantage of preventing repeated attacks by using the random "nonce" provided by the server to the client, for example:

A1 = string.hashMD5 (username + ":" + realm + ":" + password) A2 = string.hashMD5 (paramTable.method + ":" + paramTable.uri) requestdigest = string.hashMD5 (A1 + ":" + nonce + ":" + A2) 

However, in order for the server to recalculate "requestdigest", it must know the "password", but my server will only have access to the salt hash.

If I hadn’t used salt, I could add another step on the client side (since the password is known on the client side) -

 HashedPword = string.hashMD5(password) A1 = string.hashMD5 (username + ":" + realm + ":" + HashedPword) A2 = string.hashMD5 (paramTable.method + ":" + paramTable.uri) requestdigest = string.hashMD5 (A1 + ":" + nonce + ":" + A2) 

And then on the server side, I could get the Hashed password from db to do the recalculation.

Alas, the client must know the salt also in order to do it correctly, which would be, for example,

 HashedSaltedPword = string.hashMD5(password+salt) A1 = string.hashMD5 (username + ":" + realm + ":" + HashedSaltedPword) A2 = string.hashMD5 (paramTable.method + ":" + paramTable.uri) requestdigest = string.hashMD5 (A1 + ":" + nonce + ":" + A2) 

Thus, in order to pass the salt to the client without authentication, it is possible by exposing a web service function that returns the salt, given the username. But then anyone could access the salts.

What interests me is that distributing salts is a problem or not. Because the salt itself is useless without a hash stored in the database, and if the database is compromised, then the attacker will have access to both hashes and salts. And after that, if I give the salt away for free, then I can just simply use the username as the salt, as it will be unique to each user - and therefore I won’t even need to call the web service to find the salt first .

What do you guys think? Does it have salt exposure or has a known salting mechanism? Any other thoughts?

I'm not really worried about the lack of digesting authentication, i.e. that the client does not know if he is talking to a "real" server or not. Because it is not like the client password will be opened using this method, and I do not ask the client anything confidential from this link, like a credit card. That is, the things that I want to protect are on my server, and the server will not ask the client for any of their secure information.

Edit: hmm, actually I just read this link Salt, passwords and security , which basically confirmed to me that knowing the salt doesn't matter. Therefore, I am thinking of implementing some hash type, for example:

 HashedSaltedPword = string.hashMD5(password+username+siteWideSaltExistingOnlyInCode) 

Adding a common salt in case someone created rainbow tables for a common username. Is this approach safe?

Answer 1

You must choose how you want to pass the password. Do you want to transfer it only hashed from the client side to the server? In this case, the server must store passwords, otherwise it will not be able to recalculate the hash. Do you want the server to not store passwords? In this case, you must transfer the password to plain text so that the server can calculate the hash and compare it with the saved one.

In the first case, you need to store passwords in the database, and if you want to protect them, you must use data-level encryption at the database / application level. In a later case, secure transport (HTTPS, VPN, etc.) is required, since passwords are transmitted in a readable form.