Signing http requests

Question

Information Security

There is some kind of API for mobile applications that needs to be protected. I would like to sign requests in order to discard unsigned requests or requests from blocked clients when accessing the backend.

Are there ready-made practices, cases for such tasks?

Now the following scheme is emerging, but due to the peculiarities of thinking it is difficult for me to assess its sufficiency:

The application receives an api-key when it first accesses the backend. In addition, a secret string is hardwired into the application, which is known only to the client and the backend and which is not passed between them.

After receiving the api-key, the application signs each request with a string generated from the api-key + secret + something else.

sign = hmac-sha1( api-key + secret + md5(request data) )

That is, the api-key is transmitted in the request (the device / user is identified by it) and sign. The backend, knowing sign and secret, can check the signature for validity.

Is that enough or complete bullshit? Maybe it's enough just to establish a connection via HTTPS and that's it?

Answer 1

I used a similar solution for myself, I just added the creation date:
ApiKey="iphone_key", Signature="a048d4fb029cc191874ebb787893e708", Created="2013-08-28T17:43:09+04:00"
By the creation date, you can cut out obsolete requests ( for example, which were created earlier than 5 minutes ago). Otherwise, by intercepting the request, it can be used at least a year later.
Well, all important operations (billing, passwords) are of course via https.

Answer 2

There is no protection. You can always hack apk or ipa and see what's what. We also made signing and https, but this is more likely from those who want to figure us out in five minutes. Who needs it - will open it. We are ready for this.
OAuth is not about anything at all.

Answer 3

The salt on the left is bad :)
I can sign any request without knowing the key using the length extension attack.

Answer 4

You can read the OAuth 2.0 RFC 6749 standard .
There, by the way, it is written that the secret cannot be stored on the client, it is used for northern interaction.

Answer 5

I had a similar solution - all AJAX requests were encrypted by blowfish using the user's password, which he specified during login

Answer 6

If there are no contraindications against HTTPS with mutual authentication, then this is the most correct option.
When amateurs (from the point of view of cryptography) start to reinvent the wheel, this usually does not lead to good.