It is sent to the server, instead of the clear-text password. This isn't really necessary if you're using HTTPS, however.

Sending a straight hash of the password is no more secure than sending the password in cleartext - an attacker can just replay the hash they sniffed off the network.

As skyebook said, use HTTPS. There's no excuse.

This practice is more to prevent the user's password from being revealed than it is to prevent others from logging in as you. In a trusted environment, you may not care that someone there has access to your account, but you don't want them to know what password you chose.

Having said that, do use HTTPS when possible, but keep in mind some corporate environments force proxies that can see your traffic anyway.

I agree there's no excuse not to use (and force) HTTPS, but the parent did say:

> hash your secret key together along with other data unique to your HTTP request, in particular the headers and the datetime

So that isn't a straight hash and you can't just trivially replay. It does require you store the secret in the clear (or at least reversibly) on the server, but I see a lot of APIs do that...

For anyone reading: please just use HTTPS!