How to develop a private Restfull API?

Asked

Viewed 1,160 times

7

I need to develop a Restfull HTTP API in PHP to serve as authentication for users of an Android application, the problem is that as it is a public distribution application I can not define any key in the code as for example: basic authentication key, because it runs the risk of code (APK) being broken and key discovered, but also I can not leave the API open so that it can be accessible from a browser, but should be accessible only from my application.

What should I follow to do this? and how to make sure that only my Android app will have access to the API?

I want to avoid unwanted requests from other sources.

  • From the server’s point of view, he has no way of knowing for sure what kind of application made the HTTP request. You can identify the client program in most cases by the property user-agent of the requisition, but it’s manipulable, and any 12-year-old boy who’s vacated knows how to do that. Don’t lose sleep because of this requirement of not being able to access the API from browser as it is a lost fight ;)

  • @Raphaelcastro on the one hand is a public API but then does not want public. Maybe the concept is a little confused. If your app has public distribution which means it can be executed at any point... So your API really has to manage those requests that come from anywhere. You need to think like this....

  • That’s what I was thinking, it’s probably better to strengthen the server-side application than to keep breaking your head with the client-side.

  • @Raphaelcastro That’s right. It is the server that has to dictate the rules and with the definitions the API appears naturally. However remember that developing a root authentication system is no easy task.

  • Unfortunately I will say, regardless of the solution what you want is not possible, at one point or another the same can be broken, simulated or emulated. Asymmetrical or symmetrical key doesn’t change that. All these techniques will only hinder, never inhibit the actions of someone with knowledge and interest. In these cases you should work with the kind of security that is worth it. Do not put something too complex because you need to maintain, or put something too sophisticated, because maybe a simple key will never be seen. It all depends on the type of application and the interest of those who are aware.

  • HTTPS is a must-have so that your api is not intercepted. Search for the implementation of the Oauth2.0 protocol, in case for android applications you will need to implement client_credential. You can also prevent a "Trust", a hash based on something unique within the application (checksum would be possible?) to ensure that the request is actually coming from your application.

  • PHP has functions to impel a hash-based authentication, take a look https://en.wikipedia.org/wiki/Hash-based_message_authentication_code And also look at this question, have insights relevant to your problem : https://security.stackexchange.com/questions/18572/is-it-okay-for-api-secret-to-be-stored-in-plain-text-or-decrypt-able

Show 2 more comments

2 answers

7


I think you can define a key in the code yes, as long as the encryption algorithm is asymmetrical.

It works as follows: you have a pair of keys, the public and the private. These names are arbitrary and serve only to reflect the fact that you keep one of them just for yourself. What matters in asymmetric key encryption is that anything you encrypt with the public key can only be decrypted by the private (and depending on the algorithm used, the reciprocal can also be true).

Use the private key on your authentication server and deliver the public key to your application without fear. After the client application encrypts the credentials to send to the server with the public key, only the private key - which only you have - can decrypt that information. So you are unconcerned about us stealing authentication data while they traffic.

  • My concern is with using the key to rescue API data from another application, such as a GET or POST request from a php script that generates the same public key. What I need to do is make sure that only my application will be able to access this API.

  • 2

    "(...) which generates the same public key (...)". That is the problem. If you keep your boot vector secret and use something even pseudo-random to generate your key pair, the chance of someone generating the same public key (and therefore the same private) should be less than the chances of you winning at mega-sena several times in a row.

  • I think the following: If the code of an APK can be broken, and if someone has a copy of this code, therefore can not also access the API? where the application is for public distribution (Anyone may download a copy).

  • If anyone can download a copy, what difference does it make to you if the guy is using the APK that you delivered or one that he mounted himself?

  • Precisely, what I want to do is this differentiation so that requests that might want to take advantage of my API are avoided. Example: (As Tinder / Instagram does not have its data delivered to a "clone" and malicious application?)

  • With lawyers. If one of these appears in the Play! or in the App Store, they get the store to hold the kiddy script.

  • @Rafaelalexandre with a good snifer and a data not encrypted anyone (even without opening your APK) will be able to see your api key (that’s why of https). The most important thing is to protect what is being trafficked, treating the information sent or received between the client and the server with an asymmetric encryption as well answered by Renan.

Show 2 more comments

0

Unfortunately I will say, regardless of the solution what you want is not possible, at one point or another the same can be broken, simulated or emulated.

Asymmetric or symmetric key does not change this.

All these techniques will only hinder but never inhibit the actions of someone with knowledge and interest.

In these cases you should work with the kind of security that is worth it. Do not put something too complex because you need to maintain, or put something too sophisticated, because maybe a simple key will never be seen. It all depends on the type of application and the interest of those who know.

Giving only one line to guide yourself, see how to obscure your code. Using Java merge with C also helps.

Obscurcer can also be used at the API level, but in these cases you use something like Swagger to define the API, and then some other solution depending on the language to shuffle the requests.

Use SSL on endpoint makes the break difficult, if used together as GRPC already increases the level of complexity with performance gains but with increased spending on infrastructure.

One solution is to use a key in each version of APK. Whenever a new version leaves you disable the access of 1 or 2 previous versions, if you join this with the GRPC, and perhaps with the generation of 'login' per installed application, each keeping a registered key, or even a login where you return a key to be used (asymmetrical) where you can selectively cancel as you wish.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.