API credential protection guidelines as part of the iPhone app

Question

The applications I create often have requirements for services on social networks; eg.

• Twitter
• bit.ly
• Facebook

For most of these services, I need to have an API key. I am trying to develop a better way to include these API keys in the application binary. The desired level of security depends on possible attacks that could be carried out by cybercriminals.

Twitter

• I have a key and secret with xAuth support. Both must be used by the iPhone application.

Fallout from attack

• Malicious users may post twitter status updates disguising themselves as inbox from my application. There is no twitter account to capture and start publishing status updates.

bit.ly

• I have a username, password and API key.
• To enter the site and gain access to analytics, you must enter a username and password.
• To create links via the API, my iPhone applications only require a username and API key. The password will not be in the application in any form.

Fallout from attack

• Malicious users may link to my bit.ly account. They will need to make a separate attack for brute force or otherwise get a password to enter the account.

For both of these services, the potential harm does not seem too great. But for other services, it can be much worse.

I can simply define the API credentials as lines in the header or in a line in the code, but then it is vulnerable to someone using the lines in the application to see what is in it.

Then I could start doing stupid / xor -ing concatenation in the code to recreate the API key in memory, and the attacker would have to work a bit to recover any keys in binary format. My concern is that I am not a cryptographer and create there an embarrassingly weak form of obfuscation there.

What are the best deals people have?

Answer 1

An attacker can simply sniff your traffic and extract the secret from there. Thus, any obfuscation is easily circumvented.

Even SSL will not help, since you can intercept the network API that receives unencrypted data.

A safe way to solve this is to create your own server, keep a secret server on the server side and use your own server from your application, and then the server will switch to another web service. Thus, an attacker never has access to a secret.

Answer 2

A good suggestion is not to worry about it. There are many applications that store their API keys in plain text. The fact is that you need a lot of different bits of information to create an access token.

As long as you do not store the username and password commands in text form on the file system or transfer them over the network without SSL / HTTPS, etc., then you are fine.