Best way to secure Private REST API without user a

问题:

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.

回答1:

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.

回答2:

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"

回答3:

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.

回答4:

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