Security for iPhoneiPad Banking Apps

Apparently, according to a recent survey, "54% of Bankers Call Creating Mobile Corporate Banking Services a High Priority".

Yet their primary concern is mobile device security. Asked about the biggest barriers to growth in mobile corporate banking, 77% cited fraud and security concerns.

Having designed and led a team to build an iPhone/iPad app for a major Wall Street bank, I know first hand that this is a serious concern inside the firm.

Here are a few steps you can take: 

Don't store any sensitive information on the device. Actually we don't store anything at all, other than the login username, and this is only if the app user chooses to save this for ease of future login. Citigroup reported a security flaw in it's iPhone app in July 2010. The problem: they were storing sensitive information on the device.

Check for a jailbroken device at startup. When a device is jailbroken, you can gain full access (root access) to unlock all features of the said operating system, thereby removing limitations imposed by Apple. This means a hacker can get at the apps and the data on the device. They might even be able to decrypt your application binary and determine the logic, communication endpoints, and more.

Ensure that all external communication is secure. Use secure protocols when communicating with external bank systems (HTTPS, SSL, etc). We actually implemented an additional redirection layer on top of this.

App timeout and/or closure upon exit. In case a phone is left somewhere unlocked or let's say without a password on the device, you want to make sure someone can't just pickup the device and get to the app without providing credentials. You can employ a timeout on the app, requiring login after let's say 5 minutes of inactivity.

Apple also has an option in it's build settings called "Application does not run in background". This is in the build plist file and if checked, when the home button is pressed the application will close completely, requiring a reload. The default setting is unselected, meaning that the app stays in memory unless the device is rebooted. In this case, you had better employ some kind of timeout period requiring credentials after timeout.

Hire an external vendor to perform a penetration test. We hired a 3rd party security specialist firm to do this. They tested all communication endpoint urls as well as the protocol and the actual device. This is a relatively new area, so find a vendor that has experience with mobile device security.