I am building Rest APIs for an iPhone app using the PHP framework CodeIgniter. Please let me know how I can ensure that the API is accessible via the app only. This means that if anyone wants to access the APIs from outside the app, it should not be accessible.
-
7The answer is simple: "You can't."– CodesInChaosCommented Aug 26, 2016 at 9:38
-
2Also, this is a DRM question, not a security question.– CodesInChaosCommented Aug 26, 2016 at 9:40
-
1Can you can clarify the problem here? Are you concerned with valid users of your app trying to use the API or other people trying to use the API?– JimmyJamesCommented Aug 30, 2016 at 16:43
Add a comment
|
3 Answers
(You should really post this on the Cryptography group as well - https://crypto.stackexchange.com/)
It is technically possible with the right OS vendor support:
- The OS has a TPM (probably already true), which is hardware-signed by the Vendor (ie. Apple) (This may also already be true)
- Your app gets a Device-Application certificate from the TPM (May be possible)
- When your app connects to your RESTful server, it uses mTLS and only trusts client certificates that are signed by CA that asserts its model and specs and is signed by vendor Cert (ie. Apple) (Feasible).
- You might be able to use mainstream Web Server (ie. NGinx), or you might need to customize an opensource Web Server. (That can Reverse Proxy to the PHP application)
The TPM assures (in theory and most practice) that no one can extract the CA certificate, nor the Device-Application certificate. Basically, the mTLS client-side certificate signing occurs in the TPM co-processor and the private key never leaves the enclave.
Desktop PCs have got most (if not all) of what is needed. Modern iOS phones and some models of Android may also have what is needed.
The point of HTTP and REST APIs is to ease interoperability with clients. This is a feature you don't want.
You may want to decrease ease of hacking your app by using a less clear protocol for which there is less client tools available. But this will just be security through obscurity. Nothing will stop a motivated hacker from decompiling the client app.
I don't get why would you do that. But it can be done (almost).
It will require some effort and probably will not be so useful. And this could be hacked.
Why could be hacked? Because you cannot limit devices, they are "client side". So they could be faked.
You can send from your server a unique user tracking code to the APP. Only to logged users. This way you can bind the Device + App + User to this CODE via cookie or local storage.
Then you should use a filter in your server API routes to require this unique ID. You can store this user_tracking_code in your user table for validation.
-
That's security by obscurity. Even though these "solutions" add a sense of security, they are all easy to bypass with simple reverse engineering techniques.– Ext3hCommented Sep 26, 2016 at 8:57
-
-
Even that extension to authentication scheme you suggested isn't solving anything. "Could" be hacked? It's defacto broken at the same instant someone starts reverse engineering the authentication scheme at all. It gives you absolutely no guarantees on the integrity of the client, and is only ever useful to stop a 3rd party when combined with a 2-factor auth while using the known device ID to provide the 2nd factor.– Ext3hCommented Sep 27, 2016 at 15:17
-
This solution is a simple filter. It can be bypassed. I didn't read a solution of yours. Security by obscurity could filter 99,9% of attempts. If a hacker wants to exploit a non server-side access, it's always available. Everything could be reverse enginered. That always depends upon a particular need of your app. Technically you are right, but in practice you might not, depends on many factors of a particular software. Commented Sep 27, 2016 at 16:15