Thanks for that post Craig. I'm anxious to upgrade to get a look at the API. I think this info will save quite a bit of time figuring it out.
As far as sending the the salt in plain text, my opinion is your going to be okay. A few things to consider:
- First, everyone should be using HTTPS in production. Overhead is low and certs are cheap. So it shouldn't be completely plain text.
- When you log into the web interface on any website, you also send your password in plain text, so this is at least not human readable. You could hash client side with javascript, but then the same salt is used everywhere and your algorithm is public.
- If you store the salt on the server side, you have to send a plain text password and let the server hash it, which isn't bad, just definitely not more secure.
- If the traffic with the salt is sniffed, the token will be sniffed just as easily.
- Just the simple act of salting, even if the salt is known, prevents a pre-computed hash lookup.
- The only purpose of the salt really is to prevent dictionary attacks, so complex passwords without salt are equal to any password with salt.
Even knowing the salt, cracking a SHA1 hash is far from trivial as long as a complex password is used so a dictionary attack can't be used. Last I read I think it was 9 months using a machine that costs in the $100k range. SHA256 is near impossible.
Are there more secure ways to do this? Yes. Not use a password auth at all. In today's world though, password authentication is considered acceptable and there just is not a perfect way to handle passing a password.
Disclaimer, I'm no expert either. Just a conversation I've had many times with other developers to ensure I'm building things the best way.