HMAC secret key client storage

Question

I've read numerous articles about using HMAC and the secret key for client authentication in a RESTful client (Javascript) application today. Still, I don't find a single source that is able to transparently explain to me a process that fills the security gaps in the theory.

The secret key is supposed to be secret, which means that only that specific client and the server should know about the key. Since the secret key should not be transferred over the network, it should be sent over a secure medium such as email. I will not use SSL/TLS, so sending the secret key as a response from the server at login is not an option.

When questioning security, it makes no sense to me. The only reason why the user would access his email for my application, would be on registration (to activate the account).

• My first thought is that a cookie is not safe, but is there another way to store the secret key on the client?
• When the user clears his cookies, the secret key is lost. It doesn't feel very logical to send another email with a new secret key every time the cookies are gone, that wouldn't make any sense to the user.
• The user will use multiple clients, and a separate secret key should be generated for each client. Setting the key on registration does not sound like an option.

The only thing that would make sense to me is that the client gets its hands on the secret key when the user logs in, as there is no reason to keep the key when the user logs off (or after a certain expiry time).

So the question is easy:

How does the user get the secret key at login, and where is it stored at the client so that it is safe?

I feel a bit surprised that I cannot seem to figure this out. Lots of answers on the same question seem to beat around the bush, but never hit the sweet spot that makes me understand.

Edit: After another day of research, I can only conclude that an SSL connection is really required. I just can't see it any other way.
Anyway you put it, the secret has to get to both the client and server.
If this is true, I don't see why so many websites and blogs I've read point to using HMAC as alternative for Basic Auth + SSL. If there is no transparent way to share the secret key between server and client @ login time, then for me there is no use in using HMAC at all.

I find this a pity, as in the RESTful environment, every request sent to the server requires to be authenticated individually.
My application is supposed to send a lot of requests to the server for an hypothetical high amount of people, I am afraid for the overhead that SSL will cause.
Do correct me if I see this wrongly.

Answer 1

Yes, SSL is required, at the very least to transfer the "code" to the client, i.e. all of the HTML and JavaScript. You could transfer the key using SSL when the client logs in, using a secure cookie, and then have the client-side JavaScript code make non-SSL HTTP requests using the key contained in that secure cookie. However, this adds a lot of complexity, and SSL would be simpler, less error-prone, and probably faster anyway since cryptography in JavaScript is likely to be slower than the SSL implementation in the web browser and web server. Furthermore, unless the data is extremely non-sensitive, you should encrypt the requests and responses, in which case SSL would be needed anyway (there would be no benefit in trying to do the encryption in JavaScript).