Our Insights Post 5 mins Arran Kirkup Data Security in App Development – Part 1 – Developing for iOS Data security in app development means protecting digital data, such as that in a database or stored on a user’s mobile device, from destructive forces and from the unwanted actions of unauthorized users; such as a cyberattack or a data breach. Frequency of use and convenience mean that mobile apps often store important private data which can be exposed if you don’t develop your app in line with Data Security best practices.The key threats involved in App Data Security are: User data leak – Usually users will be giving you some level of their personal data while using your app. Storing this data in an unsecured manner means it could be leaked if the device falls into the wrong hands. Man in the middle attack – Intercepting http(s) requests and responses is relatively easy to do when it comes to apps and, unfortunately, SSL is not enough to make your app secure. Using commonly available tools even an amateur can become familiar with an app’s requests and the corresponding server responses then manipulate network traffic by sending doctored requests. Reverse engineering – By reverse engineering an attacker could obtain the URL addresses, identifiers and keys that you use in your application as well as gain an understanding of your business logic or steal your intellectual property. They could also potentially modify the behaviour of your application. Developing for iOS iOS, due to its closed system and restrictions imposed by Apple, is considered one of the most secure mobile operating systems. This does not mean, however, that you can neglect security when developing an iOS application. User Data Leak In order to protect user data, focus on two aspects – using the right solutions for data storage, and securing data as it’s entered. Logins, keys, and passwords should be stored in Keychain. Keychain is the password management system developed by Apple, distributed both with macOS and iOS. The iOS version is simpler, and sharing Keychain items between different apps is not possible on iOS. This means that iOS Keychain items are only accessible to the app that created them. For other, less critical, data you can make use of other tools for storage. Core Data and Realm Database are two examples. Core Data is Apple’s persistence framework with an underlying SQLite database. This means that developers interface with Core Data methods rather than the database itself. The part that’s important to us is that SQLite is not encrypted when the app is unlocked. Apple has a feature called “Data Protection” which encrypts the sandbox if the device is locked with a passcode but developers can’t rely on the user setting a passcode on their device. In this case it can be worth using a third party tool which allows you to encrypt SQLite even while the device is unlocked – for example the Encrypted Core Data SQLite Store. Alternatively the Realm Database is an open source alternative to SQLite and Core Data which means you can simply encrypt data using AES-256 encryption; even when the device is unlocked. You can store the encryption key securely in the system Keychain. Another area for protecting data is user input. We need to be aware that the keyboards used in iOS cache data for auto-correction. Auto-correction should be turned off for fields used for sensitive user data input. A similar case exists for screenshots. When an app goes to the background the system takes a screenshot. If users input sensitive data and it is visible on screen then you’ll need to implement a mechanism for masking the screen before the app goes to background. Man in the Middle Attack When making a TLS connection the client checks two things – that the server’s certificate matches the requested hostname and then that it has a chain of trust back to a trusted root certificate. However, it doesn’t check if the certificate is the specific certificate you know your server is using. This could be a potential security vulnerability. If the client were compromised and an unsafe certificate installed you could be subjected to a man in the middle attack. To solve this problem you can use certificate pinning. This is where you store a certificate on your client to ensure that SSL requests match the certificate present on the server. TrustKit is an open source library to implement SSL pinning for iOS. It’s an easier and more flexible solution than the older method of using ServerTrustPolicy which required you to store the certificate itself inside the app. Once you have TrustKit integrated in your project, you just need to enable it, for example in your AppDelegate file. Reverse Engineering When it comes to reverse engineering unfortunately there isn’t a great deal you can do. A significantly motivated attacker will always be able to reverse engineer your application. Where possible any sensitive information should be stored server side rather than client side. Developing your application in Swift rather than Objective C could potentially be an improvement but only because, as an older language, there are more well developed tools for reverse engineering Objective C. It’s also worth using a tool like CocoaPods Keys as a secure way of storing application keys for particular environments. Finally, you could attempt to obfuscate important data by using misleading method names, creating traps and fake methods for an attacker. Unfortunately this can make code harder to maintain, slower to develop and more error prone.
