Securing an API for mobile access

Question

I've built a nice REST/JSON API that is used by other companies (our clients) as a B2B service. Each of our clients has a username/password pair, and we also do HTTPS and validate the source IP of requests to service. Service usage costs money, and client is billed monthly for his usage of service.

Now, some of clients are building mobile applications that they hand out to their users (B2C - end users). Not all of these end users of our service have servers and they wish to use service directly from the smartphone (which technically isn't big deal being JSON/REST).

The problem is I'm not sure how to protect the service against fraud. What will prevent a third party developer to disassemble one of client's mobile application and copy their username/password/whatever security credentials and use that in his application? That would allow him to consume the service and charge the usage to one of our legit clients!

I'm pretty sure there is no perfect crypto solution to this problem unless end users are mandated to authenticate to some server. But that is not always the case.

As a last resort I guess I can distribute an obfuscated library for Android / IPhone, which would at least give the illusion of security...

EDIT (clarification):

Let me try to simplify the scenario.

1. I have an un-hackable web server which serves out a JSON REST API.
2. Mobile clients access my API directly. Their IPs cannot be validated. They are running a standard OS (Android / IOS).
3. There are no other servers involved.
4. I cannot access the phones' IMEI (it is considered private), nor would this help me because I don't know the end users.
5. There are several such legal mobile applications, developed by different companies that access our API.
6. Current security (username/password) is easily hackable by rogue company. Said rogue company disassembles a legit mobile application and copies the username/password to their illegal application. They distribute this application and profit (API usage is charged to the company from which they stole the credentials).

Can this be stopped?

Answer 1

Your question is "Can this be stopped?", but I get the feeling that anything significant about the system can't/won't really be changed.

If I understand correctly, you are asking (simplified):

I have many clients sharing the same username and password. Can I stop misuse?

The answer to that is no. You must decide if you can afford to ignore the problem, or implement correct solutions.

If you really want to do this properly, look into implementing something like OAuth, so you can properly distribute separate auth tokens for end users, link them to your clients for billing, revoke access, etc.

--

The least you should do is allow your clients (the companies) to opt into using a better auth scheme. So, for example, you create an API for them to request (and revoke) separate access tokens for their end-users.

• Company A requests token from their servers (this is initiated by their app telling them "give me a token")
• You return token N, record what company it's attached to
• If Company A-s app connects to your service, it sends the token N, and not username/password
• Company A can tell your service "revoke token N", and futher requests with that token will not be served by your service. But, if a token is revoked, it won't render all client apps unusable.

If a company does not want to do this, they can still continue connecting using their username/password, but they would be completely responsible for all resulting usage.

The point is that you can't really hold your clients accountable for leaking credentials (something that is impossible to do in a mobile app scenario) if they have no other way to use the service.

Answer 2

So I hope I have this correct. You want a secure way of confirming the identity of a client using a valid API key? I think that securely storing the API key is largely responsible on the company that developed the application and not your company.

You will need to encrypt and obfuscate the key to protect it from the casual hacker but I don't think you will ever be able to prevent a determined hacker. You could do a bit of hackery to make the binary harder to debug which may reduce the chances of your app floating around the internet. However, this is not absolute security and unless your company is developing the applications in-house how can you enforce such measures?

So as an answer to your scenario, no, I don't think it can be effectively stopped without being detrimental to the users experience. You can educate the companies using your API- throw together a little handbook for them and make sure it is clear it is their responsibility to keep their api key secure.

On your end, you could also implement some mitigation features. For example:

1. Allow companies to define their own hard limits. Say company A knows that last month they had N app downloads and thus want to limit their access to your API to X requests per day or hour.
2. Monitor any spikes in requests per company per time period.
3. Define a step of procedures that would occur upon potential fraudulent activities.
4. Re-key, re-key, and re-key.

The goal on failure (it happens to the best) is to minimise the damage.

Goodluck.

Answer 3

You are right to be skeptical about your clients embedding their username/password in a mobile app that they hand out to all their users. As you have correctly identified, it would be easy for some attacker to disassemble that mobile app, pull out the username/password from the mobile app, and use it in their own app. Unfortunately, your client is the one who decides whether to do that, but the cost is imposed on you. So, this is an externality, and you'll need some way to make the costs and risks and incentives better-aligned. I have some suggestions below about how to do that.

Generally speaking, I see two plausible solutions to this:

• Risk transfer. For each client, impose a limit on how many requests you will accept from that client. Tell the clients that it is their responsibility to keep their username/password secure, that all requests that arrive using this username/password will be counted against their limit, and if too many requests arrive, their account may be disabled. Tell them that if they embed their username/password in a mobile app, that there is a risk that someone nefarious might steal the username/password and use it to make many requests, causing their account to be disabled and their mobile app to stop working. Let them decide whether they want to take the risk or not.

• Contractual requirements. Tell your clients they are prohibited from sharing their username/password with others, and it is not permissible for them to embed their username/password in apps that are downloadable by others. Tell them that if you detect any violations of this policy, their account may be disabled and they may be billed for any costs that this imposes upon your servers.

  If your clients want to create a mobile app, tell your clients that, instead of embedding their own username/password in the mobile app, they should proxy such requests their their own server. In other words, the client should set up a server that knows the client's username/password, but this username/password should not be embedded in the mobile app. The client's mobile app should authenticate to the client's server, send a request to the server, and then the server should forward the request to you and forward the response back to the mobile app. Their server should authenticate the end user (e.g., require each end user of the mobile app to create an account on their server, with their own username/password). Their server should impose bandwidth limits on a per-user basis, and disable the account of any end user who exceeds those limits.

You could also allow clients to choose between these two options: e.g., between a limited-bandwidth account (with risk transfer), or an unlimited-bandwidth account (with a requirement not to embed the username/password in apps that are accesible to others).

I hope this makes sense. This may be a bit confusing, because there are three parties -- you, your client, and your client's end user -- each with their own interests and concerns. I hope I've adequately distinguished between all three.

Answer 4

One of the issue I think you will face on the mobile front is the IP address validation. Typically the mobile IP addresses assigned by the telco will be netted. The netted IP will make the IP validation mechanism adopted in the server side of no use.

To implement the solution on Android and Iphone's; I think the approach should be:

1. Have the client server authentication in SSL mode be extended to client certificate validation as well. I mean let the client and server both use certificates to establish secure SSL session.
2. Deliver the PFX/P12 containing the client certificate (mobile) in such a way that it requires a PIN and combination of IMEI and IMSI numbers. This way it will become tough for an attacker to repudiate the same session.
3. Have some AI implemented on the server which detects two or more concurrent session initiated using the same client certificate which will let you know that some compromise have had happened and the server can immediately blacklist or revoke the certificate for further usage.

I believe though we were discussing for mobile environment; other than IP validation, the risks are present in PC environment also. In future you can adopt or migrate to signature based and client certificate based implementation on PC environment as well if you get some wrong billing issues raised by clients.

Answer 5

Fraud is vauge and cannot be address by just a technical implementation, but if you have implemented escalated IP validation and lockdown, then nothing to worry about. You must also not give the actual credentials to your clients (B2B). Let me explain why and how.

From my understanding of what you have written, the basic to average security concepts and implementations have already been applied concerning the B2B side (YOURCOMPANY - YOURCLIENT). That's good. IP Validation, SSL/TLS, User/Pass etc. Now, you are concerned that the API credentials used by your clients to deliver mobile applications to end-users can be flawed in a manner that a 3rd party end-user would take advantage of these credentials if the mobile app of your client has been exploited in some way.

Basically it boils down to a series of security layers. The question is how your company have designed and implemented these layers?

1. Your JSON/REST API SERVER should contain your actual credentials. If you are delivering a service and requires a connection to a network provider/carrier then those credentials can be find here too. You know what I mean.

2. Do not give YOURCLIENT direct access to the JSON/REST API SERVER. Instead, you need a jump host which will serve as the host for the trusted environment, the API server from where your JSON/REST application resides should authenticate ONLY with this server using IP Address validation/lockdown. Server to server authentication using IP or public/private key pairs. Its your discretion what to use.

This server should also act as a web-service containing a set of username/passwords which then maps itself to a configuration file and passing the request to the JSON/REST API SERVER. Now, YOURCLIENTS should have access to this server on the basis of IP validation/lockdown too and protected using HTTPS. The concept is that no actual user/pass credentials can be found here except for the key/secret that maps to the API SERVER.

1. YOURCLIENT can have a security implemention from within their side to the end-users. It can be in a form of PKI public/private key pair for developers or a 2FA for ordinary users. YOURCLIENT should implement these steps, not your company.

Now for example, a 3rd party developer (end-user) had exploited a flaw on a mobile application created by one of YOURCLIENT and got their credentials:

1. Useless. Concerning that in order to use the credentials, your IP will be validated.
2. Invalid. Concerning that you must have been authenticated via public/private key pair.
3. Privilege escalation technique will require him to exploit the actual server in order to be trusted.
4. Exploiting the actual server requires crafted techniques which will slow down an attacker's motivation.
5. There is no successful attack which motivation has ended.

Obfuscation is good and slows down an attack but it is the least form of security. You should rely better on crypto which uses keys.

Remember, there is no absolute security solution aside from your continuous effort to battle fraud from within a technical and operational security perspective.

Answer 6

Securing your data in transmission with SSL has already covered the man-in-middle attack. Passwords hard-coded in the source code is anyways not a secure practice. You should not care for IP address of users or IMEI. Let's not talk about tracking and try to fix things in the first place.

Like you said, you are using REST. Few things should help you out, I hope.

1. Authenticate the users from the server side. Maintain strict session managements so that it cannot be forged. Check out OWASP for this.
2. Do a fuzz test for your API. ReST is known for few vulnerabilities. Please explore them on Internet and get to know most of the known bugs in ReST. Patch those issues for your API.
3. Your SSL thing is good that it is protecting your data in the middle.

Don't worry about your source code. It can can be ripped out anyways but that's ok. Your major functions shall be running on server and just passing the responses to the clients. Keep all the good things on the server side.