Securing your software product is one of the key, non-negotiable items you need to do before you release it and make it available to customers. Regardless of who you are, security should be top-of-mind when you build your Windows Phone apps as well. In this post, we’ll go over tips and tricks on how you can secure your Windows Phone app as well as touch on the various types of security you need to keep in mind when building your app.
Let’s call a spade a spade and say unequivocally that the world of technology is a vastly different and more dangerous place than it ever was even 10 years ago (or perhaps even one year ago…). The days where functionality of software being the primary focus are now gone, being replaced by a combination of functionality, experience, ubiquity, manageability and certainly not the least of which is security.
The world continues to change with new and stronger threats to be challenged every day. This includes our software creations. Clearly a black market economy has emerged around technology, specifically in getting data from software that may be valuable to unsavoury people looking to gain insights to the information that the software (or data stores used by the software) can provide.
There is an amazing book by James Gleick call The Information: A History, A Theory A Flood that talks about what information is, how it has evolved and explains in great detail what the value of information truly is. In it, Gleick makes a case for why information is important and how it has become a means for people to gain a competitive advantage.
When you look at software in its fundamental form (regardless of the channel – mobile, pc-based, web, service or otherwise), the only purpose it serves is to provide you, the user, with data that you can transform into information that you or your business can act upon based on the facts or probabilities it provides. The true value of your software is the information it holds.
Because the information your software product holds on your users’ behalf is valuable, you need to protect it. The viability and future of your software depends on your ability to build trust with the user and that includes making sure nothing that non-authorized users shouldn’t see gets leaked to them.
When I am talking to others about data security, I’m reminded of a great scene from the movie Heat (one of my all-time favourites, actually). The scene is near the beginning of the movie where Robert DeNiro’s character and Jon Voigt’s character meet with a man that knows when a certain bank is going to get an influx of bearer bonds in their vaults (which, of course, they decide to steal). At the end of the scene, DeNiro asks the man “How do you know this stuff?” to which the man answers (and I am paraphrasing) “It’s in the airwaves, all around us. You just have to know how to find it. I know how to find it.”.
That scene is actually really telling. You get a sense for how the human mind can find correlations across disparate, almost seemingly non-connected bits of data (in the case of the movie, the ability to get building blueprints from city, having information that a large shipment of bonds will be in the vault at a certain date and time, electrical schematics for disabling that specific bank’s alarms, etc.). Basically, your software is in a eternal battle against the vastness of intelligence and creativity of the human mind. Sounds daunting, right? Well, luckily for us as software developers, there are a number of tried and tested best practices that we can use to protect our software and they also work for Windows Phone. Some of these are listed below:
Since mobile devices figure out ways to get lost, if your app is expected to handle sensitive data (by sensitive, I mean private, confidential, etc.), make sure your data footprint on that device is minimal. A great example of this is the way banks in implement mobile banking apps in general on smartphones (and web browsers for that matter). Account numbers are never kept on the device – instead, mobile banking apps tend to use transient tokens (i.e.: non-permanent tokens that go stale after a certain amount of time) on the device that is paired specifically to that device and the user on the server side. In other words, full account data is not kept on the device and any data kept on the device goes stale quickly.
After figuring out what data would need to reside locally (however transiently) for your app to work, you must architect and plan for that data to be encrypted and isolated from other apps and system functions. Please remember, however, that if you are worried about security and privacy within your app and you have the option to store that data server-side, you should always do so.
In Windows Phone, make use of isolated storage for your local data. You can (and in the case of sensitive data, should) encrypt the data in isolated storage. Oh, and don’t “roll your own” encryption algorithms – you should use those provided by the .NET platform for Windows Phone if at all possible as they are tested and proven solid. That is, unless you love cryptomath, love creating salted hashes and get giddy at the though of getting home from work and scheming up new encryption methods to thwart hackers (if that rocks your boat, I strongly suggest you grab a copy of the applied cryptography bible written by Bruce Schneier – it’s a great book but not for the faint of heart).
(By the way, extra credit for those that can identify the typewriter-looking-thingy associated with this section!)
Challenge/Response is an old security pattern, but it is one that is very effective. Especially true in Line-of-Business app scenarios, but equally relevant in any case where you want users to prove their identity to the app, Challenge/Response is basically a request made by the app to authenticate themselves before they are let in the gate. Authentication is the process by which a user provides a user name and password (or something similar like biometric feedback or other methods) to basically act as a proxy to the app demonstrating the user is who he/she say she/he is. That’s all it is – permission to enter the property.
Authorization, on the other hand, is where the second line of defence resides and it is also the way apps with well-architected security really shine, in my opinion. Once you have authenticated, the app knows who you are. At that point, the app (and any server-side logic the app consumes) uses your credentials to determine what data you will have access to. For example, if your app was a fantasy football pool, a football league commissioner would likely have the ability to set new rules and send special, league-wide notifications to the members of the league, while as a regular league member using the same app would have access to only his/her fantasy football team. Authorization is the magic that makes this happen.
There are very few scenarios where you have a mobile app that has a requirement for security and encryption that doesn’t have a server-side or internet connectivity component. As such, make sure your mobile app does have a central management capability outside of the app itself (likely a web app for the server or something similar). If something goes wrong (especially if it affects more than one individual user), you are going to need a way to fix the issue quickly and through ways that won’t require you as a manager of the central data to have physical access to the app on the user’s device.
There are many more ways to secure your phone apps, to be sure, but these are some of the ones to start a discussion. Throughout the following weeks, stay tuned for further posts around data security in Windows Phone apps.
Cryptography. Rule. Number. One. DON'T ROLL YOUR OWN even if you want to! :)
Building on what Paul said, here's some food for thought around authentication for developers: passwords are evil. If you make someone remember yet another password (Y.A.P.) you too are evil. :) Consider using a federated authentication scenario where you delegate the role of authentication to some other service like LiveID or Google or Facebook. Sometimes that isn't always the best option like with the banking app scenario above, but it may make a lot of sense in a social app.
Aaaaaaaand the typewriter thingy is a German Enigma Machine from WWII. It's cipher system was cracked because an analyst kept hitting the 'E' key repeatedly and realized that the outputted value never returned an 'E'. See rule number one. :)
I was under the impression Windows Phone 7 didn't support things like device encryption or strong device management?
You are correct. Windows Phone 7.x does not support full device encryption. What I spoke of (unclearly, apologies for that!) is to encrypt data at the data item level, for example things like column level encryption or string encryption. Hopefully that makes more sense!
Great point about passwords - single sign-on / Federated security is a great option in enterprise/LOB scenarios, without a doubt. If you are building non-enterprise or LOB apps, you may not be able to federate your ID in the business sense, but you can still use implementations like OAuth, Live ID and other "consumer-oriented" solutions for limiting the need for new user ID's and passwords.
Aaaaaaaaand you are correct on identifying the Enigma machine. :)
Or you can outsource Identity all together, taking the full oweness off of the phone. Windows Azure's Access Control Service connects all of the major consumer identity providers and puts them up as a service that your phone can use to authenticate. Moreover, ACS can also federate with your on-premises Active Directory, giving you the ability to single-sign on to your phone app using your corporate AD. Check out http://azurecamp.ca/azurec04 for a deeper look at the Access Control Service.
Absolutely right, Jonathan! ACS is a great way to delegate identity to the cloud securely. Would love to hear if anyone has examples of how they did this with Windows Phone!