26

I am making some Restful APIs for my mobile application.

The communication between APP and webserver has to be made in REST. These apis should be private , and only my app should able to call them for successful results.

The tough part is, there is no user id and password required in my app so i do not know how could i restrict rest API with the mobile app without basic user authentication.

One solution i thought was to embed some kind of hardcode string so when mobile app will use the restful url they will pass that in encryption format over ssl. But i know this seems like very bad solution..

kindly suggest what should be the best solution under such situation.

wolvorinePk
  • 1,760
  • 5
  • 36
  • 67
  • http://stackoverflow.com/questions/6134082/restful-web-service-how-to-authenticate-requests-from-other-services – Subin Sebastian Jan 31 '15 at 12:21
  • 3
    You can see from the discussion that , what you are asking is nearly impossible to achieve. We can authenticate users, not application. Only possible approach is some kind of shared secret. But if your client application is reverse engineer able, it s not safe and achieves nothing. – Subin Sebastian Jan 31 '15 at 12:28
  • When it comes to Reverse Engineering, nothing can stand against it. However it is very easy to make their job harder and harder. What about if I embed my secret in form of some complicated math formula / function? – Nasir Iqbal Feb 03 '15 at 05:51
  • sounds nice that if some one make his secret key in shape of mathematical formula and based on some values coming from the server and client it generates the key. – wolvorinePk Feb 05 '15 at 12:37

4 Answers4

7

Take a look to the Hash-based message authentication code (HMAC) mechanism.

Wikipedia link: http://en.wikipedia.org/wiki/Hash-based_message_authentication_code

Your client (mobile app) will need a public API key that identifies the REST webservice client and a private / cryptographic key. The public API key can be send along with the HTTP request. It is public and everyone can see it. The private key, however should never be sent along with the request, and should only be known by the server and client. This key is used to generate the hashed message that instead will be sent to the server. The HMAC can be generated using a SHA1 / MD5 algorithm, a message that should be generated by an algorithm that both server and client know and, finally, the private key.

Emanuel Miranda
  • 887
  • 8
  • 7
  • 3
    but i have one question , do you suggest the private key i should embed inside the code for mobile app since its not a browser. I actually do not understand where should i save my private key if i put in code then what if someone able to reverse engineer it. I think this approach can save me from the spy who is sniffing the data . – wolvorinePk Feb 02 '15 at 16:17
  • 2
    Yes you are right. If you store the private key in the code / configuration file there is that chance, and i don't think it is possible to make it bulletproof. However, you can make things harder. I'm not very familiar with the common techniques, but check out this question: http://stackoverflow.com/questions/8184492/best-way-to-secure-android-app-sensitive-data. Hope it helps! – Emanuel Miranda Feb 02 '15 at 16:38
5

Your are right, embedded key in app can be easily retrieved by packet sniffers or various other techniques. You can overcome this issue by using following instructions.

  • client (your app) will call required API
  • server will reject it, but in response it will send a string containing random hash (=challenge).
  • client uses that string in combination with some other string (=password) (already embedded in app) to generate a new hash (=digest)
  • client will call same API again but this time using newly created digest as authentication parameters.
  • server will validate that digest and will proceed

FYI: the above mentioned procedure is widly accepted standard and being referred as Digest Authentication. If you need more help then just ask Google for "android http digest authentication"

Nasir Iqbal
  • 909
  • 7
  • 24
  • 1
    i think it is nice but adding public and private key crypto can make it more secure. – wolvorinePk Feb 02 '15 at 16:53
  • Agreed! I think digest authentication is very easy to implement and also provide fair-enough security. However if you are so consious about your APP then you should definitely go with key based encrypted communication. – Nasir Iqbal Feb 03 '15 at 05:38
  • 8
    The mobile app could still be inspected to find the other string (=password). – Westy92 Jun 26 '17 at 18:18
1

You can indeed make the job harder for reverse engineers but can't make it bulletproof, as Nasir said, by introducing mathematically hard problems and transforming your hard coded string accordingly.

How about this. Suppose a number A hardcoded in app. Server sends two numbers B & P (P is a large prime). Now you can calculate the actual number that will be validated by server using (A^B) % P. Your app now encrypts the answer of (A^B)%P with Server's Public Key. Server will decrypt it with its private key, validate it and will issue a token (jwt maybe) with an expiration time. Then your app and server can communicate using that token. You can perform the calculations once when the app boots and store the token for further use.

Javapocalypse
  • 2,223
  • 17
  • 23
0

I would suggest creating a complex token in app, made of the timestamp + appId + any other value that you can replicate on the server, and authenticate in the header of each request using those.

For example you could create a virtual "user" in your db and store in it the deviceToken and use it for your algorithm.

I personally keep one API request public, which is the timestamp getter, which returns the timestamp of the server to use within 300 seconds.

so before each request, get the timestamp, and send your created token, replicate it on the server, and thus authenticate the request.

A mediocre hacker can reverse engineer the app and replicate your tokens though

Ralph Melhem
  • 767
  • 5
  • 12