Simplifying app security: what are the best app security measures for you?
In our penultimate instalment of our “Simplifying app security” series by Senior Consultant John Barker, we cover how to define the best app security measures for your app – what’s recommended, what’s essential and what’s totally dependent on your solution. If you’ve missed the other articles so far, start here.
In an ideal world, you’d use every security measure available to you.
But in reality, that just isn’t feasible – or necessary, in a lot of cases.
Even the best app security measures on the market will impede the user experience in some way, so the more checks and restrictions you have in place, the more frustrated your users will become.
Today’s blog post will serve as a guide to the kind of security features we recommend, the ones we don’t always use and why – hopefully, it will help you decide on the best app security measures for your solution…
Security measures we recommend
- What is it? This term refers to things like finger print or facial recognition technology. If available through the device, we’d require this as an added layer of security, to access any sensitive data stored at rest on the app
- UX impact? It’s simple to include and the user can always opt out of it, keeping disruption to a minimum
- What is it? A standard security feature for most apps, this is where all data imported by the user should be validated to ensure that it matches an expected format, such as a postcode, phone number or bank card number
- UX impact? This is a widely accepted (even expected) security measure, so you won’t cause any added frustration for the user with this
At Rest and In Transit Encryption
- What is it? Where data must be stored locally on the user’s device, all sensitive data should be encrypted – plus, when being transmitted, that data should also be encrypted; Bluetooth and analytics systems such as Firebase enable this kind of encryption by default
- UX impact? None! It’s totally invisible to the user
- What is it? A useful UI feature, this is where (when the app is no longer in the foreground) all data can be hidden or blurred on the devices carousel of recently-used apps. This stops other applications from capturing any sensitive data that the app is currently displaying
- UX impact? Little to none, as the user isn’t actually using the app when this security measure is actually happening
- What is it? This feature allows your app to block screenshots from being taken when it’s in the foreground, thereby stopping other apps from getting access to anything sensitive. This isn’t possible with current iOS versions
- UX impact? This doesn’t have an impact on the user, but it does affect technical support, as developers can’t ask users to screenshot what’s happening when they encounter a bug in the app
- What is it? The app’s code can be obfuscated during the build, to hinder attempts to reverse engineer the code (this is done automatically in iOS)
- UX impact? None at all! It’s all done during the app’s development, so never has any implications once the solution has launched
Security features that depend on your app
- What is it? This is where we validate the Public Key or Certificate of the server to block man-in-the-middle type attacks on HTTPS connections
- Why might we use it? Public key pinning is preferable from a maintenance viewpoint; the security certificates you use to “pin” the connection need to be re-created annually. So, if you pin to the public key (which is re-used between certificates when done correctly), you don’t need to rebuild the app to include the newly-created certificate – making things easier, faster and cheaper later on.
- What’s the compromise? Pinning can sometimes block the user from using the app if they’re connected via a public Wi-Fi – if this is a frequent use case, pinning probably isn’t for you. Pinning to a certificate also requires the app to be updated every time the certificate is renewed, which could be once a year.
- What is it? This allows you to convert sensitive information into tokens as soon as possible to reduce the exposure to outside attacks.
- Why might we use it? This can be a crucial security feature for many, but only when sensitive information is being transmitted to external destinations
- What’s the compromise? Minor – the only compromise here is that it involves an extra step for the user, when the tokenisation information is actually used
- What is it? This is where we use heuristics to assess whether the device has been jailbroken – simply put, we attempt to detect the presence of files that are present on jailbroken phones, or, try to carry out commands that always fail on a non-jailbroken device, but could succeed on a jailbroken device
- Why might we use it? For apps using sensitive or personal data, such as banking or health
- What’s the compromise? This approach can lead to false positives where valid users are blocked from using the application. Plus, many enthusiasts have a “home-brewed” version of Android, which jailbreak detection might erroneously think is already jailbroken
Tap-Jacking for Android
- What is it? This technique detects when an overlay is on the screen – something a malicious app could use to detect keypresses.
- Why might we use it? Any time the user enters a password or passcode – a pretty common task!
- What’s the compromise? This feature can stop the application working with many other valid apps, such as Facebook messenger, that use overlays without malicious intent
What are the best app security measures for you and your app?
The ones listed above in the recommended section are pretty set in stone – any app developer worth their salt should suggest implementing these to you.
But when it comes to some of those additional ones, which potentially impact on the performance of the solution or its popularity with users, how do you define what the best app security measures for your app are?
The main question we always ask our clients to consider is: “What kind of security would the app’s users be expecting?” Too high or too low, and users will stop using your app.
Of course, another key consideration from this is whether you’ve thought about how your app will be used and what security implications that could have – a topic I’ll cover in the final blog post of this series.