Posts Tagged ‘Instagram’

Does your IOS App welcome attackers with open arms ?

May 27, 2011 1 comment

I have added an HTTP sniffer on my network countless times and freely see passwords travelling back and forth between IOS apps and the servers where their APIs reside. I am sure you remember that Instagram took lot of flak when it was discovered that they were transmitting passwords in clear text across the network. The argument was that although there is zero value for anyone to hack your instagram credentials, but even the smartest of us tend to use the same login name and passwords for a lot of sites. And it doesn’t take a long time for a hacker to realize that and use your instagram login to hack your bank account or mint account or email account. SCARY !!!!!!

I am not going to detail how exactly to protect your API here but here is a quick thought on how to easily do it without SSL (call it poor man’s SSL). We have used an advanced form of encryption and rolling/expiring tokens to protect our API from prying eyes in Loqly. Here is the iTunes link: (it is free!)

  • When you launch your app, contact your server to get a random key
  • Every API call you make to the server from now on should send this key back to the server using any simple encryption algorithm. If nothing else, just base64 encode it. The server should then validate that every API call contains this key.
  • Along with the above key send some token which will expire after X minutes. eg. 10 minutes

What will you get from this? If a hacker is sniffing your network and he sees the exact API call and copies it, guess what? He cannot make that call more than X minutes at which time the validity of that API call expires. Which means nobody can use DOS attacks to bring down your entire server.

But in the above sentence the hacker can use your API call for at least X minutes. Well, in that case send some random number(encrypted) with every API call. The server should then reject API calls with the same number in them (i.e copy /paste API URLs will not work for the hacker)

Also, think of rejecting API calls not originating from a certain USER_AGENT. i.e people trying to paste your API calls into your browsers should be slapped in their face if they are coming from Mozilla, IE, Safari, Chrome etc. Your IOS app can modify the USER_AGENT and insert its own value in there.

Also, try to HTTP POST these security keys to make it a little more difficult for the hacker to call your API. An HTTP GET call is as simple as copying and pasting it on the browser.