A month with Swift and iOS Development

I never would have imagined I would touch iOS development. I have been an avid Android user since the birth of the Samsung Galaxy series. Actually, I was led down that path mainly because my experimental jailbroken 3gs iPhone was buggy. I had the last of it when the glass shattered on a vent and had trouble replacing the glass myself. I never thought I would be back to an iPhone. Besides, Android devices are just more open and allow for easier experimentation.

Enter 2015 when I thought I would give the iPhone another try after 5 years of hating. The iPhone 6 is a nice design. I was intrigued about the experience of a seamless experience across multiple form factors and I have somewhat liked what I have been my Mac, iPad and iPhone. I still think the notes app sucks (so glad google keep is now on iOS).

Having done quite a bit of Android dev and mobile dev using PhoneGap in its early days, the thought of using Objective-C was scary enough for me to never consider iOS development. That all changed with Swift. I have grown to love the expressiveness of languages like Ruby and Python. Any language that follows a similar form is sure to catch my attention. Swift has done just that.

It is not quite as flexible as Python, my go to prototype/hack language, but for a mobile development and on iOS Swift feels like a home run. I actually enjoy doing this now and finally gave the development tools that Apple provides a chance. I am one happy customer. The idea of writing this post really came from a Udacity course I’m currently going through titled Intro to iOS Development with Swift. I would highly recommend it for anyone looking to get their feet wet.

All in all, I like Swift and development for my iOS devices is now an exciting endeavor I never thought I would embark on.

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 ↑