Secure API Authentication method

Question

We are working on a new project, we are two lead developers and got on a cross road on how to use a token to secure the communication between the server and the client :

First Suggestion :

Step one) the client requests a primary token, by sending the username and password and the current_time (this variable will be saved in the server's database and the client side too) to the api, the server interprets the input, and renders a hashed token (e.g. : 58f52c075aca5d3e07869598c4d66648) saves it in the database and returns it to the client.

Step Two) The client now saves the primary token, and creates new hashed token using the primary token + the current_time variable sent in the authentication request (lets call this new token, main_token) also the server does the same and create the same token using the same algorithm.

Step Three) Each time the client queries the server API, it sends the main_token to the server, now the server compares the token generated in it, with the main_token sent by the client, if it matches, it means the user is real

Second Suggestion :

Step One) The client generates two random keys ($key1 = rand(10000,90000); $key2 = rand(10000,90000);) On each request on the API, the client creates a hash using the query type, and the two keys with a complex algorithm, and sends these two keys + the hash to the server

Step Two) The server, using the same Algorithm used in the client, creates a hash, and compares is to the one sent by the client, if it matches, the server proceeds to deal with the query

---

Now, the question is, Which one is the most logical, and secure way to use for securing the api requests

Best Regards

Answer 1

Neither of the solutions has any benefit to security.

First suggestion

Once I have main_token, I can compute any hash(main_token + timestamp). All I need to access the API is the main_token, so why bother with the timestamp business?

Second suggestion

If you send the two random numbers with each request and the query type, then what is stopping me from doing the same and using your APIs? The algorithm? The rule with cryptography algorithms is if you roll your own, someone will crack it. Second rule is security by obscurity doesn't work.

If your authentication process is more secure than your api, you could protect the calls a different way:

Authentication phase (SSL)

1. client sends user/password and gets a 'Secret_token' which is a random string.
2. Secret_token is stored client side and server side.
3. Secret_token is never transferred over the wire again.

API Request Phase

1. client creates a request
2. client normalizes request
3. client calculates a signature* of the normalized request using Secret_token
4. client sends the request + signature to server
5. server normalizes request
6. server calculates a signature of the normalized request using the Secret_token
7. if signatures match, server proceeds with request

Calculate a signature

First, normalize the request. This might mean extracting the important parameters including method (post,get,action,timestamp) and putting them in order. Then running that string through HMAC algorithm which takes the Secret_token as a parameter.

Analysis

The Secret_token is only transferred over the wire one time when the authentication happens. It's assumed the authentication process is very secure (as the password is transferred during this process, it's a safe assumption).

Note: still not safe to send over plaintext, use SSL.

HMAC is a well known solution. See:

• http://rc3.org/2011/12/02/using-hmac-to-authenticate-web-service-requests/
• most of amazon's apis are hmac signed: http://docs.aws.amazon.com/general/latest/gr/signature-version-2.html
• https://www.rfc-editor.org/rfc/rfc2104
• http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/