BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
How can mobile developers address security concerns around Wi-Fi connections and other untrusted networks?
Step one for development teams is to understand that mobile devices make connections to Wi-Fi, Bluetooth and telephone carrier networks, most of which should not be trusted. All of these connectivity options can leave traffic open to inspection and manipulation from a variety of attackers.
Application developers should never rely on the users of their apps to make decisions about which networks will ensure the app behaves in a secure manner. They should build proper controls into the apps themselves so that users don't have to assume any responsibility for security.
Mobile developers should then encrypt all network traffic that the app sends and receives over Wi-Fi connections and other networks. They should use proper configuration settings to force proper behavior for applications using this encryption. The most straightforward way to encrypt network traffic in mobile apps is usually by using the Secure Sockets Layer (SSL) protocol. When properly configured, this protocol will encrypt traffic so that it can't be observed or surreptitiously modified in transit. In addition, the SSL protocol, if properly applied, will help to authenticate the server the app is communicating -- making sure that the app is talking to the intended organization. This server authentication is important in most sensitive communications. And it is especially critical for mobile apps because it can help to protect against some weaknesses in the way Domain Name Service (DNS) is used to direct app traffic to servers. This server authentication can be used to guard against situations where a mobile app connects to an untrusted network.
The specifics of creating well-configured SSL network connections vary on a platform-to-platform basis, but the major mobile platforms, such as iOS (iPhone and iPad) and Android, provide built-in libraries for making SSL connections, as well as for SSL-enabled versions of other protocols such as HTTPS. In addition, in many cases the default settings for these libraries have reasonably secure default behaviors. However, developers should look to make sure that encryption is required for SSL connections and that server-authentication controls are not diminished or disabled. Mobile app clients should enforce server authentication and should not be configured to accept expired server certificates.
One area where many development teams run into problems is dealing with the fact that applications in development often communicate with different servers from when they are in production. Many organizations do not purchase server-side certificates for development and test servers -- only for production servers. In cases like this, one option to consider is designing the application to toggle between a "development" setting -- where server-side authentication is disabled -- and a "production" setting where server-side authentication is enforced. There's a drawback to this approach: If app builds are released into production without the production setting, the application will not enforce server-side authentication. Another alternative is to internally generate certificates for development and staging servers, and to configure test devices to recognize the self-signed, internally generated certificates as valid.