The Mobile App Security Mantra: Don’t Trust, But Verify

Although the technological designs of mobile devices have much in common with non-mobile computer systems, there are substantial differences that need to be understood. Here’s what mobile app developers should consider about the threat vectors they need to protect against.

Security on Computer vs. Mobile Ecosystems
Smartphone hardware and software technologies are radically different from that of computers. In terms of communication, on a computer you have one external communication channel -- whereas on a smartphone you have IP connectivity, Bluetooth connectivity, Cellular Data connectivity, NFC connectivity and so on. In terms of an operating system, mobile OSs are substantially more “closed” than desktop, laptop and enterprise OSs.

While at first glance this might make a mobile OS appear more secure, it’s truly a double-edged sword when -- not if -- threats manage to penetrate the OS defenses. As Luis Blando, vice president of engineering at McAfee, explains, “once the mobile OS is penetrated, the products and systems that would otherwise be able to protect the device (such as those made by security ISVs) would be limited in the protective actions they can take within the OS guardrails, and that can prevent quarantining, pre-emption or even detection.”

The mobile ecosystem is also very different from that of regular desktop computing in the number of viable operating systems, the types of application delivery mechanisms, and established policies for application acceptance. In the desktop world, with a simple visit to a URL, a user can download and install a binary which can very well be infected. In the mobile world, application download and installation is done mostly through approved stores that curate the apps.

That said, these app store checks can create a false sense of protection. “When we recently checked the origin of infected mobile software, as reported by the MMS user base, we discovered that the majority had been downloaded directly from major app stores,” Blando notes. “And, in Asia, the use of specialized app stores, which may or may not have any curation or security checks on their catalog, is widespread. Don’t think that just because you’re using GooglePlay or another major app store that it’s a guarantee of safety.”

Possibly even more significantly, there are vast differences in the usage models for mobile and regular computing devices. Mobile devices are with you all the time, record your every move, log your every communication, and are a treasure trove of both personal and corporate information. Smartphones contain much more information than the average computing device; it’s your phone, calendar, address book, camera, music station, remote control, ATM, shopping assistant, and more. The fact that smartphones are incredibly valuable for information theft pretty much guarantees that the supposedly secure “defenses” built in via technology or ecosystems as explained above will sooner or later be overcome. “Smartphones are simply irresistible as targets,” says Blando.

Despite these huge challenges, “mobile applications are often not tested at all for security, or are not tested in as much detail as traditional web applications,” notes Brian Shura, Vice President at AppSec Consulting. “The security testing toolset that is available for mobile applications is not that mature. A thorough assessment involves a large amount of manual testing combined with some automated tools. Large financial companies have the resources to perform detailed mobile application security assessments, but the majority of applications available from the App Store most likely have never undergone a thorough security assessment.”

Mobile Developers Have to “Think Differently” About Security
Mobile developers need to adopt a mobile security mindset. Although, in many ways, mobile devices are computers and developers need to treat them as such, nothing on a mobile device eliminates the need for secure coding practices. All programs should sanitize input, only request the permissions that are absolutely necessary, and never store passwords or user data in clear text.

That said, mobile software does present new security challenges both from the point of view of secure software but also of protecting the user. Any mobile developer’s first priority should always be to protect the user. One key is to never let the illusion of security or safety suggested by either a closed OS or a single-user device fool you.

Mobile software developers need to keep in mind some new challenges on mobile devices:

•      Network mobility: Mobile devices connect to many networks. Most users will connect to any open WiFi hotspot they can find as a method of reducing cellular data usage. This means that mobile software, even more than desktop software, must never trust that the network is secure. In addition to eavesdropping, mobile software developers should be wary of hostile networks that may attempt to impersonate servers or services. Apps should encrypt all network data and verify servers and services before sending authentication credentials.

•      Device usage: Mobile devices are, well, mobile. Smartphones and other mobile devices go everywhere with their owners. They are also often taken out, used for a short time, and then set down. This means that they are also quite often lost or temporarily available to strangers. This frequent and on-the-go usage means that most mobile devices are not password protected. This is in contrast to laptops that are much more often password protected and are used less often and for longer stretches of time.

Mobile software that handles sensitive data should offer users the ability to separately lock the application or access to the data. Shura explains that’s why “developers need to take this into account and build their applications in a way that a stolen mobile device doesn’t lead to an application user account compromise. For the most part, this means ensuring that sensitive information, such as passwords, are not stored on the mobile device.”

•      Screen size: Smaller screens display less data. Screen size needs to be factored in when presenting the user with secure data or data they need to verify. One example is the URL input and display field in a browser. Most desktop browsers partially rely on the fact that a user can see the entire URL in this field. This is one line of defense against phishing attacks. The URL field on a mobile browser is so small, though, that only a fraction of the URL can be shown. This hides relevant data from the user and creates a new vulnerability. Keep in mind the size of the screen so that verification data displays are short or the most important data are displayed first.

How Can App Developers Help Users Keep Private Data Safe?
While “in the past, developers of mobile applications did not have many resources to turn to for security guidance, that’s definitely starting to change,” says Shura. “OWASP (Open Web Application Security Project) now has a Mobile Security Project, which includes an OWASP Mobile Top 10 List of common vulnerabilities to avoid, Mobile Cheat Sheets for developers, and lots of testing guidance for people that are performing mobile application security assessments. I encourage mobile application developers to become familiar with the resources that are available on the OWASP website.”

Blando notes that, depending on the OS, there are also some specific issues to be wary of:

On Android:

•      Be careful creating services, as any application on the device may have access to it.

•      Treat incoming intents as hostile input -- sanitize and check the data they provide before acting on it.

•      Make sure files stored on the device are protected both with file system permissions as well as other data protection techniques like obfuscation or encryption.

•      Assume the user already has root access to the device.

On iOS

•      Assume the phone is jail-broken. That's not to rely on jail-broken behaviors, but to write your software as if the user already has full access to the device instead of relying on the OS to provide sandboxing to isolate your data from the user's view.

The Bottom Line: Don’t assume anything. Don’t trust. Verify.

Additional developer guidelines can be found at the U.S. Federal Trade Commission website: Mobile App Developers: Start with Security.

The Android-iOS Data Disparity

It's one of the biggest mysteries in wireless these days: More people worldwide own Android smartphones and tablets, yet iOS devices often drive the lion's share of Web traffic from handheld devices.

For example, during the first five weeks of 2013, iOS devices drove almost 7 percent of all traffic on non-cellular networks -- while Android accounted for 2 percent. That’s according to Akamai’s IO portal, which tracks usage across a variety of browser types. Another company, Net Applications, says iOS devices drove about 60 percent of mobile traffic each month over the past year.

These kinds of differences aren’t academic. Instead, they’re things that developers should keep an eye on because they affect the market for their apps. The catch is that the differences melt away or flip-flop depending on factors such as network type and device type.

For example, the disparity reverses when the devices are connected to cellular rather than WiFi. In that case, Android accounted for 23 percent of traffic, compared to 20 percent for iOS, Akamai found. iOS leads on WiFi because of  the iPad, whose owners typically forgo the cellular option.

“Out of that 7 percent of overall traffic that iOS accounted for on non-cellular networks, 4.2 percent was iPad,” says Guy Podjarny, CTO of Akamai’s Web Experience business unit. “It’s the iPad that tips the balance when you talk about browser market share, but it has a very small foothold in cellular traffic.” You can read more about data disparities here.

 

Behind the Numbers of iOS vs. Android Data Usage
There’s no shortage of theories about why these differences exist. For example, some thing that vendor and operator pricing encourages people who are replacing their feature phone to buy an Android device even though they have little interest in more than voice and text. If that’s correct, then the addressable market for Android apps isn’t as large as it seems.

A related issue is that unless an operator is subsidizing the heck out of an Android smartphone, a low price often indicates mediocre hardware capabilities. That too can affect whether owners of those devices are a good fit for apps that work best when the phone has a powerful processor and lots of memory.

“While top-range Android devices are on par -- and in several cases higher spec -- than iPhones, there is a large amount of Android devices that are much lower spec, providing a sub-par user experience that could also affect user engagement,” says Andreas Pappas, senior analyst at VisionMobile.

The relationship between OS choices and audience engagement level also plays out overseas, but for other reasons. “Android is popular in countries where mobile broadband and even fixed broadband has low penetration (e.g., China),” Pappas says. “In these markets, access to the Internet via mobile devices can be much lower than in the U.S., preventing users from engaging with online services.” 

In any part of the world, demographics can be an even bigger factor. “It is most likely that the same demographic group will have similar levels of engagement on either platform,” Pappas says. “So if you take 100 iPhone users and 100 Android users among, say, users that are industry analysts, you will probably observe, more or less, the same engagement pattern.”

That’s an example of why it can be more important to focus on the target demographic’s attributes rather than fixating on whether developing a native Android or iOS app is the best way to reach as many potential customers as possible.

“I don’t think the usage gap justifies [targeting] one over the other,” Podjarny says. “I would look at statistics around conversion percentages, how likely are iOS users to pay for something or click on an ad versus Android users, or is one platform more dramatically popular than another within your target audience.”

 

 

Change Is the Only Constant
A mobile operating system’s market share, brand perception and app usage can change dramatically in just a year. Think back to the fall of BlackBerry and the rise of Android. So if you’re going to use information on data usage to decide, for example, which OS to develop for first, look for numbers that are no more than a couple of quarters old.

“Android is making inroads both in developed and developing markets and is no longer considered the cheaper/alternative platform," Pappas says. “Android devices have come a long way and they offer features that are not available on the iPhone (e.g., NFC), making them the preferred choice for a lot of tech-savvy people.”

What’s more, “data usage on Android is likely to approach the levels of iPhone usage as they are increasingly being adopted by data-hungry users,” Pappas continues. “User engagement on low-cost Android devices (feature phone replacements) is likely to rise as users get up to speed with apps and better understand the use cases enabled via smartphones.”  

There's a Map for That

Mobile’s value proposition is ultimately convenience: anytime, anywhere access to people and information. Hence the value of adding maps and other navigation features to apps.

For mobile app developers, there’s no shortage of map solutions. One factor to consider is the app’s target platform and what it natively includes.

“Google Maps is superior in terms of coverage and precision, especially in remote areas,” says Mette Lykke, co-founder of Endomondo, whose apps combine fitness with social networking. “Until recently this was the natural choice for apps on Android and iOS. It still is for Android.”

Apple’s dumping of Google Maps might be the best-known example of how the field of mapping options isn’t static, but it’s not the only major change in the past year. In June, Microsoft announced that Nokia Maps would replace Bing Maps in Windows Phone. And in November, Nokia announced HERE, a multi-device and -OS solution that will expand to Android in early 2013.

Map Features: Web-Based or Native?
When comparing options, one factor for mobile app developers is whether to use a native map library or a Java Script API (JSAPI) Web-based map. Each option has its pros and cons. For example, one consideration is whether the app needs to target multiple platforms, such as Android and iOS.

“The Web-based map enables cross-platform support, which will save the developer the effort in writing a separate mapping code for each platform,” says Oded Nevo, platform product manager at Telmap, an Intel-owned company that specializes in location services. [Disclosure: Intel is the sponsor of this content.]

“However, choosing the Web-based map will mean in many cases that developers will need to slightly compromise the map performance,” he continues. “Choosing to use a native library will mean coding the map section per each platform. However, you will get a slicker map behavior.”

Factors to Consider in Choosing a Map Feature for Your Mobile App
In addition to the Web-based versus native consideration, it’s also important to research the APIs available in a mapping library. Focus on things such as the ease of implementation and whether the map feature supports all of the functions that are key for making your mobile app stand out in the market.

“Last but not least is pricing,” Nevo says. “Most of the big brands in the mapping APIs arena will offer a free quota that many developers will probably never exceed, especially if they are at the initial stages of building/developing a product.

“For more mature products which generate a large amount of traffic, developers should seek getting an SLA with the chosen mapping solution provider. This is called in many cases the ‘professional’ plan/track. Developers also need to bear in mind that there are several types of applications that are automatically being categorized under the professional plan/track license scheme. These are usually paid applications, enterprise applications or applications around asset management and tracking.”

Testing as a Service

Add software testing to the numerous IT functions now offered in the cloud. Vendor offerings are sometimes referred to as Testing as a Service (TaaS), a reference to other cloud products such as Infrastructure as a Service, Platform as a Service and Software as a Service.

Some companies provide TaaS on a fully outsourced basis -- the customer hands over the software to be tested and the vendor conducts the tests. Other testing companies, including those targeting mobile app developers, pursue a different strategy. Such vendors offer an Internet-based testing platform that lets developers remotely access an array of mobile devices on which they conduct their own app tests. This testing approach frees developers from having to acquire -- and keep track of -- multiple devices for testing purposes.

Benefits of Remote Testing Platforms
It’s easy for developers to end up with a room full of devices they purchased for testing, says Gidi Pridor, vice president, business development, at Perfecto Mobile Inc. That approachisn’t scalable and costs a considerable amount of money, a particularly pressing issue for smaller developers, he says.

Perfecto Mobile lets customers remotely access and control more than 500 mobile devices for application testing. The Boston-based company also has plans to expand, having secured a $15 million round of financing in October.

While the testing platform helps smaller firms with testing costs, there’s a plus for large enterprises as well. Pridor says a cloud-based platform eases the logistics of testing on technology that’s in a constant state of flux.

“This market changes all the time,” Pridor says. “It’s unpredictable and dynamic. Managing the relevant offerings and having everyone in your organization getting access to that is a big logistical nightmare.”

Rachel Obstler, senior director of product marketing at Keynote Systems Inc., which offers its DeviceAnywhere cloud-based mobile app testing platform, says most organizations don’t want to be in the business of buying phones for their Quality Assurance teams and then having to track those assets. Enterprises often have geographically dispersed QA teams, so ensuring accessibility to mobile devices also becomes an issue. “If organizations have a central place where [QA teams] can access devices over the Internet, it is much more efficient,” she says.

Automated Application Performance Testing
The testing platform also paves the way for automated testing. Automation is critical for reaching a level of sustainable quality for mobile apps, says Pridor. The Perfecto Mobile platform lets customers automate a test script on one device and then port it across any other device. Specifically, Perfecto Mobile’s ScriptOne technology lets QA script tests that span multiple devices, irrespective of operating system or carrier.

Similarly, DeviceAnywhere lets QA teams automate test scripts to “capture, verify and replay” user interactions on mobile devices, according to the company. “Once you have this platform, it is something you can then automate on,” Obstler says.

Platform vendors offer customers the opportunity to leverage their investment in software testing products. DeviceAnywhere, for example, can integrate with test automation tools from HP (QuickTest Professional) and IBM (Rational Quality Manager). Perfecto Mobile also offers HP and IBM integration.

Public and Dedicated Resources for Application Testing
Mobile app testing platforms offer their customers both public and private cloud access models.

Perfecto Mobile’s MobileCloud, for example, lets customers access a large pool of shared devices, Pridor explains. The service targets smaller companies. The company also delivers its platform on a private cloud basis. Large enterprises in such industries as healthcare and financial services use the private cloud model due to security and regulatory compliance concerns, says Pridor. But the larger firms may also use the public cloud to supplement their dedicated resources.

DeviceAnywhere’s shared, public system provides smaller companies a lower-cost way to tap the testing platform, says Obstler. The company’s dedicated environment, meanwhile, lets larger companies address their security needs. Enterprise customers also use the public system to augment the core handsets they access in the dedicated system, Obstler notes. A company may use 10 to 20 core handsets in the dedicated setting, but will turn to the public system to do compatibility testing on other handsets.

Photo: Corbis Images

Mobile Apps and Accessibility

When it comes to making information technology accessible to people with disabilities, websites have received much of the attention.

In 1998, Congress amended the Rehabilitation Act of 1973, directing federal agencies to make IT resources accessible to both government employees and the public. A considerable chunk of the work under the amendments -- typically referred to as Section 508 -- involves getting government websites to comply. Soon after Section 508, the World Wide Web Consortium published its Web Content Accessibility Guidelines, a set of recommendations for improving the accessibility of web content.

Recently, mobile app development has also started coming into the accessibility discussion. Developers and accessibility experts now say that the general approaches used in the web world can also apply to the rapidly expanding field of mobile devices and apps. Mobile OS makers -- including Apple, RIM/BlackBerry and Google -- even offer specific guidance on developing accessible mobile apps.

Forms of Accessibility and How to Integrate Them

Accessibility in app design may take a number of forms. For blind and low-vision users, assistive technologies include screen readers. Screen reader software, such as Apple’s VoiceOver, translates the information appearing on a display to speech. A screen reader may also drive a braille display, which raises dots through holes in a keyboard-like device to permit reading.

Examples of accommodations for deaf and hearing-impaired users include captioning services such as Purple Communications’ ClearCaptions, which debuted in 2011. In the mobile category, the service is available for Android devices and iPhones.

Mobile app developers can help widen the scope of mobile apps disabled people can use in addition to those purpose-built accessibility technologies. And the task of building accessible apps doesn’t have to be tremendously time consuming, notes Doug Brashear, mobile practice director at NavigationArts, a web and application design and development consulting firm. That’s particularly the case when the mobile OS has accessibility features baked in.

“Surprisingly, the current crop of mobile devices, particularly iPhones, has more accessibility features built into the operating system than you’d ever expect,” Brashear says. “A small amount of additional design and development time -- over what is normally required -- can yield a highly usable and accessible app.” Apple iOS’ accessibility features, for example, can get developers 75 percent of the way there, according to Brashear.

Crista Earl, director of web operations at the American Foundation for the Blind, also notes Apple’s accessibility features. Among the major capabilities: VoiceOver and Zoom. VoiceOver, she notes, originated as a screen reader for the Mac plaform and later migrated to iOS. Zoom lets users magnify an app’s entire screen as opposed to individual elements, according to Apple. Earl also says that Android, as open source software, enables app makers to develop accessible apps or apps geared toward niche markets.

Accessible App Design Tips

Many accessibility principles for websites also readily apply to mobile development. Section 508 guidelines, for instance, call for text labels to accompany images and navigational controls such as buttons. Screen readers can’t interpret a button without the supplemental text. “Put an explicit label on your controls,” Earl advises.

Similarly, web accessibility guidelines declare that information shouldn’t be conveyed only as color -- as in the case of distinguishing various subway lines on a map. Text labels provide an alternative method for conveying information here as well.

Much of what Brashear’s company would do to build a mobile app’s user interface, he says, would be the same steps it would take to create a website that complies with Section 508 or the Americans with Disabilities Act. But some elements of accessible development don’t carry over from websites to apps.

“There are a whole set of things specific to mobile because of the screen size and the fact they are touchable,” Brashear says. He suggests developers adhere to the standard UI elements for a given platform, which he says greatly aids the intuitiveness of an app. The idea is to let users leverage the experience they have had with other apps. The more customized the app, “the harder it is going to be, especially for a sight- challenged person, to understand,” Brashear says.

Developers should also enable landscape viewing as an accessibility practice, suggests Brashear, who notes that some apps lock the orientation to be portrait only. He says landscape mode is helpful in providing a bigger view, overall, and for facilitating the use of a virtual keyboard.

Brashear also cites the following mobile app accessibility recommendations:

·         Keep the need to enter text to a minimum, since small or virtual keyboards can be difficult to use.

·         Locate actions in your app away from areas of the screen that perform other functions.

·         Provide large finger targets for on-screen buttons or links.

Know Your Audience

Understanding users is central to any app project. When developing for accessibility, app makers need to “understand the nature of the challenges involved,” Brashear says

To that end, he advises developers to read, research and learn from people with accessibility needs. He points to forums such as AppleVis, a website designed for blind and low-vision users of iPhones, iPads and other Apple products.

Consulting disabled users is also important as the app moves through the development cycle. “When testing is being done, work with people who have the disabilities that you want to serve,” says Nancy Massey, president of MasseyNet.com Inc., a company which consults on accessibility and Section 508 issues.

Developers often tend to make accessibility more complicated than it needs to be, says Massey, who adds that there’s ample crossover between general usability and accessibility in the mobile technology field. An app built with a clear and simple design that’s attractive to users may go a long way toward meeting accessibility goals, she says. “What makes something user friendly often makes it accessible."