Securing web-API access

Question

I have a simple web-API accessible over HTTP with some corresponding mobile apps reading that data. Now someone decompiled an app / sniffed the HTTP traffic, got the url to my web API and built his own client acting like one of mine.

How can I secure the access to my API only for my own clients? Even with the thought of someone decompiling my app.

Server & client-side code change is an option!

Answer 1

Server & client-side code change is an option!

First, you can't prevent it completely (without legal action :). Use SSL/TLS, that will help with the sniffing posibility.

If the app is downloaded directly from your server (not through an app store/third party) you can secure it a bit more. When a user downloads the application make sure the user is authenticated, generate a key, include it in the application and use it in all further communication with that user. The hacker/thief can mimic that, but they'll need to go through their server to simulate a login and download of your application -- you can find and block that.

Answer 2

Use TLS (successor of SSL).

In short, nobody will be able to sniff the traffic, because it will be encrypted. The basic version includes only a server certificate - create a certificate (self-signed for a start) and let the server use. What happens (I won't go into the handshake specifics):

• the client sends a request
• the server responds with its public key
• the client generates a symmetric secret key (using AES or 3DES), encrypts it with the server's public key (RSA), and sends it to the server
• the server decrypts the symmetric secret key (only the server, owning the private key, can decrypt it)
• the communication continues with every message (request/response) being encrypted with the secret key that was securely transferred

Most of this is handled by the APIs you'll be using, but it's good to know how things happen.

Answer 3

How to authenticate a web request?

Basic HTTP authentication is obviously not sufficient if there's any risk of the traffic being sniffed unless its sent over HTTPS (which would be secure).

There are lots of other approaches - challenge based mechanisms (e.g. digest authentication), client certificates and SSL.

Its really a question of which solution poses the least pain - SSL certificates cost money unless you set up your certification authority (as long as you're not expecting the world to accept your certificates then its fairly simple to do), Write code to implement a challenge / hash based on a shared secret.

Or simply restrict URL access (via .htaccess) to a fixed set of ip addresses (optionally validated using IPSEC).

Answer 4

Short answer: This is a start of an arms race. You can either obfuscate and protect while your 'opponents' reverse-engineer and re-develop, OR you can focus your efforts on improving your client software enough that users would rather use your software than your 'opponents' software. I'd argue that if your clients are better tools, then your users will use your clients. If there is something your competition is doing better than you, take note.

Longer answer: when every single client is downloaded, generate a client-side x.509 certificate, sign it with a CA key. Configure your web server to require and validate the client certificate with every request.

One of your legitimate users might give their client certificate to your opponent. They might bake in one, ten, one thousand, different legitimately acquired certificates into their software, but you can knock down each individual one (publish the key into a Certificate Revocation List that your web server uses when validating the clients) as you discover them. And then deal with the individual end users who are frustrated when their keys stopped working.