When deploying mobile solutions in your enterprise, security should always be an important topic. When you have devices such as iPhones, iPads or Android smartphones that are leaving your companies facilities, it opens the door to unwanted access. This is even more critical with offline solutions. This blog will discuss the different security aspects of these applications.

It is bad enough if a smartphone comes into the wrong hands and somebody has access to an online app and therefore access to valuable business information (like data from SAP, Salesforce or other systems). But in this case the account of the user who lost his phone can be locked or the password can be changed. But let's talk about offline applications. Apps with a database on the device to allow work even if there is no network connection. If somebody has access to that, he hardly can be stopped If the data is not somehow protected. He can put the device into offline mode and therefore no device management system in the world can wipe the data. So how can offline data be protected?

Password handling

Mobile apps in the enterprise should be both enterprise grade (in regards to availability, performance and security) and consumer grade (having the same usability like consumer apps). Sometimes there must be a tradeoff between the two. For example, users of consumer apps are used to enter their password just ones to access Facebook, Twitter or LinkedIn. The app remembers the password and you are good to go. When it comes to enterprise apps you want to protect the data inside the app. Yes, all common mobile operating systems have a code/password protection on the lock screen and the use of this can even be enforced by device management solutions. But still many companies want a higher level of security. This means: Password entry when you enter the app - higher security, lower usability. No password on app startup - lower security, higher usability. You cannot have both.

Depending on how critical the information within the app are, we have the following options:

• Enter user and password ones and store it on the device. Future logins or synchronization a will not require to re-enter the password, but will use the one in stored for authentication of the user when connecting to the server.
• Enter user and password ones and store it on the device. Force the user to create a passcode that he has to enter every time he opens the app. This is more user friendly and adds a bit more security. For sync, the locally stored user and password are used.
• Enter username and password every time the user opens the app. When the user logs in the first time, a one-way hash is created out of the password (It is even better to create a salted hash, making it more difficult for brute force attacks to find the right password). This hash is stored on the device instead of the password itself. If the user logs in again, the hash is created again and compared to the one stored. If they match, the user can access the application. For the sync, we keep the password that was entered at login in memory.
• Enter username and password every time the user opens the app. When the user logs in the first time, a hash is created out of the password. This hash is stored on the device instead of the password itself. If the user logs in again, the hash is created again and compared to the one stored. If they match, the user can access the application. Now however, the password is removed from memory directly after the two hashes have been compared. As it is now not available anymore for synchronization, the user also needs to enter the password before every synchronization. After sync, it is also removed from memory.

For most use cases, we recommend options 2 or 3.

Encryption of local data

It should be clear that any communication that is done via an insecure network should be encrypted. But in the offline case we also need to think about encrypting the data stored on the mobile device. With today's tools and a little bit of background in the development of mobile apps it is possible to extract the database from the mobile device and copy it to a computer - even when the app is password protected.

I assume that every enterprise grade mobile database/data storage supports encryption. Therefore, I see the following options:

• Encrypt the database with an encryption key that is hard coded into the app. In this case the encryption key is inside the compiled code on the mobile device (Storing the encryption key in a configuration file is not a good idea. It would make it very easy for an attacker to read it). To get access to it, someone would need to decompile the code. He would need to have specific knowledge about the code and first needs to find the key, before he can use it.   There would also be the drawback that the encryption key would be the same for every device. Ones hacked, all devices would be venerable.
• Loading an individual encryption key from the server and store it in the secure storage on the mobile device. This has the advantage that key is different for every device. The secure storage is also encrypted itself, making it more difficult for attackers to read it. This of course makes the process of encrypting the DB more difficult, but also more secure.

With all that in mind it still must be said that there will never be a 100% security. As soon as data is leaving your company buildings, you will partially lose control over it. Should that stop you from deploying mobile apps? Of course not! You are able to make it very hard, if not impossible, for somebody from your competition to steal your secrets. Will it stop a government to access your data? Maybe not.

To conclude, these are the best practices for securing enterprise apps:

1. Encrypt all communication between mobile devices and servers
2. Protect the mobile device with a passcode
3. Implement a mobile device management solution to enforce password policies.
4. Protect the mobile app with a passcode or username/password
5. Encrypt the local database with a device specific encryption key
6. Only store the absolute minimum of data on the mobile device.

I hope this is helpful for you - I am looking forward to your feedback in the comments.