I'm working on a (non high security) project that currently isn't live but might go live at some point.
We have a REST API (implemented using Restlet and Neo4j) running on a server and an Android client app.
To keep things stateless, we need to send auth information together with each request. We decided to use a MAC-based approach: We sign a set of header values as well as the entity body of each HTTP request using the HMAC-SHA256 algorithm. We then put that hash together with the username in the
Authorization header of the request.
For the HMAC secret, we use a password that is chosen by the user. To make things more secure, we hash the password before using it and storing it in the client.
Of course, in order for the server to be able to validate the HMAC-SHA256 header, we need to transmit the secret once. But as this only happens a single time, it's not that much of a security risk.
The problem with this setup is the secure storage of the user passwords. I know that passwords should never be hashed without using a salt to prevent rainbow table attacks. But when I generate a secure/random salt, a client that logs a user in for the first time has no way to get access to that salt in order to generate the correct hash.
What would be the best decision in this case? Should I simply store the passwords using a "conventional" hashing algorithm like SHA256 without using a salt? I guess that would be very negligent. I could also use a more secure algorithm like bcrypt or PBKDF2 with a "dummy salt" like
the username a MD5 hash of the username and a higher iteration count. Even though the salt is known, it would be very slow and painful to generate rainbow tables.
Would bcrypt with a "security-by-obscurity" salt be secure enough? Or is the entire setup insecure and should be exchanged with another authentication method?