0

I am trying to implement a web service and need some (very) simple Authenticate to restrict access to the service.

I found out about HMAC and I think I understand how to implement it. But I have a couple of questions in mind.

Let's say I have this HTML Form on the consumer side. When making a GET/POST request to my server.

  1. Is is enough to create a hash of: public_key using the secret_key?
  2. OR, do I need to create a hash of the entire POST variables/array?

I'm thinking it would be enough to send the hash of the public_key only but just wanted to make sure and ask you guys.

I am planning to do this:

  1. Create a hash of the public_key
  2. Put the hash in a hidden field or in the URL as a param together with the public_key (or client_id) and other POST/GET variables.
  3. Receive on my server and verify the hash against the database by recreating the hash of the public_key using the secret_key.
  4. If the hash matches, I accept the POST/GET requests.

Your thoughts?

Clarification: public_key is like the client unique id where I can use to identify what secret key to use to generate the hash on the server.

wenbert
  • 5,263
  • 8
  • 48
  • 77
  • HMAC just uses one shared secret. It doesn't use a "public" key. Can you clarify what you are talking about? – erickson Jul 11 '12 at 23:09
  • Also, do you require protection against a "man-in-the-middle" who can modify requests as they pass over the network? – erickson Jul 11 '12 at 23:10
  • @erickson I have added a 'clarification' in my post above. "man-in-the-middle" meaning, change the POST variables between the client and server during the request? – wenbert Jul 11 '12 at 23:15
  • 1
    Yes, changing the POST variables would be an active man-in-the-middle attack. – erickson Jul 11 '12 at 23:23
  • So I guess then it is MUST that I create a hash of the POST variables when sending in the requests to prevent man-in-the-middle attacks. _However_, how will it affect end-users / consumers of the service when they use Flash, C#, or any other language? When you create the hash of the POST in a different programming language, do you always get the same result in with PHP? If not how to go around this? – wenbert Jul 11 '12 at 23:27
  • 1
    Use TLS. It fixes this and a host of problems you haven't even thought of yet. – erickson Jul 12 '12 at 03:42
  • 1
    before you even think of rolling your own hmac functionality, take a look at [PHP's buildin `hash_hmac()`](http://www.php.net/manual/en/function.hash-hmac.php) – Jacco Jul 12 '12 at 10:46
  • @Jacco yup thanks! I am planning on using that :) This is to generate my own "hash" from the $_POST (or similar vars) on my end to compare to the _"from the client"_ hash. – wenbert Jul 15 '12 at 21:39

2 Answers2

6

The pubkey is just used as an alternative way to recognize the user. It could be the user email as well, by the way since you don't likely want to expose your user data to their programmer (or to potential sniffers) you create a unique identifier for each user. It's all it means. Then you need a private key to sign your hash.

Of course to make it worth it you have to sign all unique request data, otherwise someone could alter your request body and you wouldn't be able to detect it (MITM attack).

You also should care of creating a timestamp that must be included in the HMAC itself, then pass it alongside with the request. This way you can make the signature expirable and so you are not exposed to replay attacks (someone steals the request and without modifying it replies it against the server, operating multiple times the same action... think what a problem if it's a request to pay for your service, your user would be very very angry with you).

Also remember (nobody does) to encrypt also the Request-URI inside the HMAC itself and also the HTTP method (aka verb) if you're using a RESTful webservice, otherwise malicious users will be able to send the request to other URIs or (using RESTful services) change the meaning of your request, so a valid GET can become a potential DELETE. An example could be: user wants to see all its data, makes a GET request, a Man in the Middle reads the request and changes GET with DELETE. You are not given the opportunity to detect that something has been changed if it's not inside your HMAC you can check about, so you receive a DELETE request and boom! you destroy all user data.

So always remember: everything is essential to your request must be validable And if you rely on a HMAC then you must encrypt everything you need to trust the request.

Also always remember to start designing your system by denying all request, then if you can validate them perform requested actions. This way you always fall back on denied requests. It's better to have a user email telling you that he cannot do something that have your user data propagated on the net.

  • if we use hmac only to identify the request was not modified by MITM attack. now how to prevent MITM read the data that we sent ? – Ahmad Dec 10 '12 at 14:57
  • The best explanation (concise and simple) on HMAC i've ever read on the internet today! – Ahsaan Yousuf Jan 11 '17 at 20:45
2

Use TLS. It fixes this and a host of problems you haven't even thought of yet.

erickson
  • 265,237
  • 58
  • 395
  • 493