Category: Technology

How Secure is Your Consumer Mobile App?

Securing Mobile

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?

0

3 Things to Consider before Versioning your API

The question of how to version your API is one with varied responses depending on who you ask. But, often times we probably jump the gun on this. A couple of things drive API changes and each may require a different approach to handle the scenario. Let’s look at a few

New API Attributes

This is straight forward. You need to add new attributes to your API. Instead of versioning your service all you need to do is make the new attributes optional. The documentation captures this change and your API is backward compatible for older apps or clients. No big deal here.

Attribute Deprecation

This situation is quite different from the first because removing a required attribute will break older clients which you don’t want. This situation requires more of a social solution than a technical solution. Just give your clients a time frame for which the attribute will be supported and communicate it clearly, using documentation, your website and social media.

A combination of this and the first approach can be seen as an expand and contract approach where you may add a new attribute which might replace two other attributes (expand) and then remove the two older attributes at a predetermined time (contract).  These scenarios once again allow you get by without API versioning.

Resource Creation

Maybe the changes you are about to make actually imply a new and different API after all. It could be a new resource created to handle some level of aggregation required in certain scenarios. Which ever the case, new resource creation is what is called for and not API versioning.

If none of these scenarios really meet what you are trying to accomplish it is possible you do need to version your API. Different approaches to doing that will be discussed in separate post. At the very least, it does make sense to pause and reflect on the end goal. What else do you consider before deciding to version for your API?

0

Why you shouldn’t use cookies for Native Mobile Authentication

Can I Take a Cookie?

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.

0

Did someone lose Architecture’s invite to the Agile party?

Image

It sure is awkward showing up to party and realizing it was invite only and you are not sure you ever got one. Similarly, there’s a weird tension that exists for any Architect that gets injected into a true Agile development environment for the first time. No longer are there extensive drawn out sessions and phases to layout a long term plan and design to build something to last ‘forever’. Scrum Teams are self organizing and everything is evolving so rapidly.

It’s likely less dramatic, but the tension is real. The open question exists : “How much architecture needs to be done upfront vs how much should be deferred until the requirements are nailed down?” In reality a rapid development environment, like Agile leaves little time to address cross cutting concerns and setting up all the infrastructure needed for a large scale system. Such an activity also requires a broad view across multiple features and teams.

There’s sort of a trade-off; You spend too much time up front planning and you lose your ability to adapt to changing requirements. You move too fast and it could be chaos. One recommendation is to go with what George Fairbanks terms “Just enough architecture.” But, what does that really mean and how does it apply to different complexity of projects? Like Rick Kazman once illustrated, building a shed is so much different to building a skyscraper. While it’s easier to operate within a self-organizing team when building the former, the latter requires more attention to detail. On the flip side, it’s simply a waste of time to devote the same amount of time upfront building a shed as you would a skyscraper.

George Fairbank’s comment is really hinting on having the right amount of architecture at the right time. Overall, I believe risk reduction should be the chief motivation in how we approach architecture in Agile. It should influence how an Architect approaches documentation and evaluation as well (twin tension points for Architects in an Agile environment).

So how do we hit the ‘Sweet spot’ between upfront planning and agility? Here are 5 things I have learned

·  Focus on what poses the greatest risk to the system’s main function and qualities. Then channel your energy to mitigate that risk.

·  Seek to architect around separation of concerns, loose coupling and decomposability.

·  Document only what is needed. If there’s no audience for your documentation you probably don’t need it. If there’s a part of the architecture that a lack of clarity for a newcomer might become a RISK for the project/system, document it. Also, starting with a design that captures simple end to end functionality upfront is a reasonable goal.

·  Lean on good code and test suites to reflect architectural patterns and decisions.

·  Emphasize experimentation (Spikes). And take advantage of such agile principles as an Architecture Runway and Technical debt. Discipline and rigor around them allow for resolving trade offs.

In conclusion, Architecture might no longer get a red carpet like it used to in dev gigs, but there’s no doubt that it definitely does have an invite to the Agile party.

3

Blog at WordPress.com.

Up ↑