Is this REST service authentication system secure?

Question

I have to implement a token based authentication for a RESTful web service. This is the first time I'm implementing security features in a software, and this is what I have in mind for now :

1. The client first authenticates through a login form(in the client application) with his email and password.
2. If the authentication succeeds, the user will get in a response a private key(randomly generated) and a token(string - randomly generated ?). The server will store in the db(or maybe a cache ?) a tuple with the following fields (email, private key, hashedToken, token expiration), where hashedToken is the value of the HMAC computed over the token, keyed with the private key.
3. The client stores the received private key and the token(in memory).
4. For every future request, the client will include in a custom header (i.e. authToken) the value of the HMAC computed over the token, keyed with the private key and the user's email(in another header) and will replace the token stored in memory with the newly generated token.
5. When the server receives the request, it checks for the tuple mathcing the email address, checks if the stored token and the received token are equal and if the token hasn't expired. If it's ok, the server updates the tuple expiration date and the hashedToken field is set to the value of HMAC computed over the old token, keyed with the private key. the server then processes the request.(no additional authentication headers or info included in the response)

Steps 1 and 2 will use HTTPS. Other requests will be sent by HTTP, since a new token is generated after each succesful request(sniffing the token would be useless for an attacker, I think).

I would like to know what are the the problems with this authentication protocol and how it could be improved.

Also, would this approach be faster than just including the email and password in a header in each request and using HTTPS?

Answer 1

The basic answer is: just use HTTPS, and basic authentication. This is much simpler. The overhead of HTTPS is slight:

• A couple of extra roundtrips when a new connection is established. But connections are kept alive between client and server, and closed only when unused for too much time, so this should not matter much. Indeed, a pure-HTTPS solution could be faster than your HTTPS/HTTP mix because it could work over a single connection for the whole procedure.

• Some network overhead, about 0.2% for bulk data (SSL record header and padding and MAC); again, this will hardly show up on measures, let alone matter.

• Some CPU overhead, but much less than usually assumed. A basic CPU core can encrypt and decrypt data at more than 100 MB/s, even without using AES-NI.

---

If you do want to use HTTP (after an initial HTTPS phase), then you must account for confidentiality and integrity issues. Your HMAC games may help with integrity, but will prevent replay attacks only as long as the server remembers the last "token value" (or hash thereof). This is state and contradicts the point of REST.

Answer 2

This approach is vulnerable to Man In The Middle attackers.

An attacker will let succeed the HTTPS initial phase, then every request intercepted by the attacker could steal a valid token if the request is not forwarded to the legitimate server.

You should use the content of the REST request when you calculate the HMAC in order to avoid giving unrestricted token to the attacker.