How Secure is Your Consumer Mobile App?

We are in a new frontier in the mobile security space. Mobile advances are happening at a rapid rate and with the arrival of wearables and the Internet of Things (IOT), standard mobile security practices have not quite kept up with the pace. Mobile is increasingly becoming our primary interface to the web and our means of exchange (ideas, experience, money etc). Fondness with our mobile devices makes it so easy for most to expose sensitive information even if this is just on the device and not on the web or social media. At the center of this mobile experience? The app ecosystem. So, how secure are these apps that simplify our daily activities?

Gartner has stated that roughly 75% of all apps will fail basic security tests through the end of 2015. So, think 3 out of 4 apps you use. It is presumptuous for any business or organization that makes or provides mobile apps to think that simply applying traditional web application security principles is sufficient. Mobile apps are significantly different than web apps in a number of ways. For one, deployment of an unsecured app feature is hard to take back. Once users have the app on their devices you cannot simply force a user to upgrade. With web, changes can happen behind the scenes and customers get the latest update when next they visit the website.

Securing mobile now requires going beyond traditional user facing security measures like password encryption, use of SSL (https) or data encryption. The mindset has to shift to App Integrity. This is because reverse engineering an unprotected app is pretty easy today. You can easily decompile most apps using free or cheap tools in less than 5 mins. And be able to see business logic and sensitive data in no time. Other than the potential for IP theft, malware insertion is a possibility. This could be a simple case of a reverse engineered app, in which malware is inserted with the app repackaged and deployed to 3rd party app stores. Jailbroken and rooted devices would be must vulnerable here. Can more be done? Yes.

Techniques like Anti Tampering Mechanisms, Code Obfuscation, White-box Cryptography (Obfuscating mobile native code, like C/C++, containing sensitive logic), Jail Break and root detection, Self Checksums are just a few ways to further harden an app. There are tools in the market that help with this, but it is vital to remember that hackers also have access to these tools and so it is critical to always add your own flavor of hardening.

In most cases, hackers given enough time, tools and motivation can almost certainly compromise your mobile app, but the goal here is to significantly reduce that risk by increasing speed bumps. This makes it even more critical to secure backend services or APIs with such things as token based authentication (ex: OAuth 2.0) as the next line of defense. It is important to consider how secure your app is because your customers security is vital to your business. So, do you know how secure your app is today?

Why you shouldn’t use cookies for Native Mobile Authentication

So, I finally decided to put up this post because internet search results seem to be limited on this topic. This is about using cookies as a form of authentication in native Mobile. I scoured the internet and came away with the impression that the answer to this question was either hush hush or everyone seemed to have just followed the bandwagon or de facto approach of using basic authentication (over https) and now OAuth 1 or 2.

Don’t get me wrong I’m a big proponent of using OAuth 2.0, but it happened to be the up and coming standard when I really got into Mobile dev and Architecture. And every so often, I get the question from old school service developers, “So, why exactly can’t you use cookies with Mobile?” and I respond “Huh… well it just doesn’t work well with it . OAuth, Yes OAuth! We should be using token based authentication and basic auth over https only as the alternate option”. I immediately walk away as fast as I can before more questions pop up.

Is it Just Me or What?

I got by with this answer for quite a while, but recently I could not take it anymore so I jumped on the ‘interwebs’, busted out google and … crickets. Here and there you see some info, but the feeling you get is that person writing kind of knew, someone who knew someone, who knew the guy who really knew the answer. So I felt a little better that maybe I’m not alone after all. Basically, sparse indirect answers.

A Bit of History

It’s probably safe to assume that if you are reading this blog you likely know how cookies work, but just in case check here for a quick run down. Basically, cookies started with Netscape’s (remember them) desire to maintain the contents of a users online cart and the rest is history. Today cookies provide a great way for storing an encrypted version of a user’s identity, so you can be remembered in subsequent requests on a web browser. So technically, this should be feasible on mobile, right?

Any Beef with the REST Based Standard?

No! Like I said before I will recommend OAuth 2.0 to anyone who has an ear to listen to me. It may not be perfect, but I certainly think it’s the best solution out there. A token based solution that never has to preserve a user’s credential on the device. How sweet. Basic Auth typically requires you send up the credential with every API request and you better do that over https. But, more than likely you have to preserve the user’s credential even if it’s just in memory. So why not cookies?

The Why Not

After much frustration and poking around, a buddy of mine found some answers at the very place I should have looked first (thanks Michael Clark and Wikipedia). The HTTP cookie page discusses drawbacks to using cookies especially on native mobile. I have to say I have not validated some of the reasons through development and extensive testing, but the reasons make complete sense. To summarize

  • Most devices do not implement cookies natively
  • Some gateways and networks strip cookies
  • Some networks simulate cookies on behalf of their mobile devices

These are reasons in addition to typical cookie issues, like expiry, theft etc. Basically, using http cookies on Mobile Native is unreliable. That is enough of a reason to avoid it like a plague. At least now you no longer have to play Houdini when asked that question. It won’t surprise me if you have found other better reasons in some remote corner of the internet as of writing this. But, I would sure like to hear what those reasons are. So, do share. I hope this has served you a real good reason for not using  cookies for native mobile authentication.

Create a free website or blog at WordPress.com.

Up ↑