I'm working on a public API for project X. System allows to register an app_id and call API methods providing it, as usual. Now, I need to develop an official mobile client for project X that should have a wider possibilities than unofficial ones built over this API.

In other words, let's think for example we have an API consisting of 5 GET methods. Now I'm going to implement 1 new PUT method and want to allow only 1 exact app_id to use it.

The security problem is that:

  1. If I simply code the check for app_id, it will be easy to overcome, just sniffing the traffic or decompling the app to find this official app_id and then pretend it

  2. Application is a mobile one, thus I can't limit access by IP

  3. Public-key cryptography, where the public key is in the client and the private keys kept in secret by the server seems equal to the problem 1. for me, isn't it?

I do believe it is not a supernova problem, so kindly suggest any reliable solutions, please.


Put a challenge-response-system in the code - the server sends "12345", the client answers with "SHA256(12345+any-secret-key)". If the server knows the "secret key", it can check the hash.

That would stop people just sniffing the network data, but the app might still get decompiled.

If you want the app to send data, you need to make a "login" first - send a request, get a challenge "12345", compute the hash, send the hash and you are logged in and can continue.

  • The proper way to implement a challenge-response system is through a HMAC, not a straight hash. – Stephane Jun 12 '15 at 15:37
  • @Florian, why should we use challenging with "12345" not just agreeing to use, for example, timestamp in hash preparation on cleint-side? – Ivan Fazaniuk Nov 2 '15 at 16:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.