Security for mobile apps

Transcription

1 November 2014 Security for mobile apps This white paper provides education on security considerations and requirements for mobile apps. 1

2 Contents Authentication & security for mobile apps 3 Securing mobile devices 4 MAM vs MDM 5 App data 6 States of data 7 User Authentication 9 Appendix A 17 Appendix B 18

3 Authentication & security for mobile apps Objective The objective of this white paper is to provide education on security considerations and requirements for mobile apps. Along with identifying security risks, considerable detail and technical examples have been used to advise on securing both mobile devices and app data separately. Audience This paper is aimed at the more technologically knowledgeable reader, although it is not intended to exclude the general reader. Introduction Security is an important consideration when developing enterprise and public apps. There are two main factors to consider when talking about security in app development: Securing the mobile devices Securing the app data This document aims to cover as many aspects of securing mobile devices and the apps running on them as possible, but first it is worth covering the main reasons for data loss and leakage in the first place: Carelessness (enterprise and public apps) Devices can be lost or stolen, so any data being stored on them needs to be secured as much as possible. Data also has to have a valid reason for being on the device in the first place, so reviewing the data caching policy of the app, during the solution architecture phase, is very important. Although devices have built in password protection, users may not use secure passwords, making devices vulnerable. Users may also choose to disable or set insecure passcodes, such as 0000, 1234 or their date of birth etc. This can provide easy access to anyone trying to retrieve information from their devices. In the case of enterprise apps, however, this can be mitigated through the use of a Mobile Device Management (MDM) solution. 3

4 Malicious 3rd Parties (enterprise and public apps) Devices can be stolen and hacked, as can the data coming into and from the device. During the initial planning phase of app development, it is important to review the data in transit to ensure the data is being sent in the most secure manner for the context of the app. Malicious employees (enterprise) Disgruntled employees exposing or leaking confidential enterprise information is hard to stop; employees need access to data in order to do their jobs. MDM and Mobile Application Management (MAM) solutions are able to mitigate this to an extent, but they cannot stop truly dedicated attempts entirely. For example, businesses can disable the ability to take screenshots, dictate which apps are allowed to open certain file types and disable copy and paste functionality, but you cannot stop someone taking a photo of the screen with another device. Granted, this has always been an issue. Employees who really want to steal documents will find ways to do so. It s just that they will turn to lower tech options to do so. Securing mobile devices Type of device Before looking into how to secure the data in your app, it s worth taking a look at the devices themselves and any policies that can be applied to them. These policies will differ depending on the category the device falls into. Most devices fall into these 3 categories: 1. Personal 2. Personal managed (BYOD) 3. Company Owned There are different approaches that can be taken for ensuring security, depending on what type of audience the app will be built for. Personal device The device is owned by the end user, in this case you will have no control over the device or the operating system. Any security features will need to be implemented as part of the app. This is most applicable for apps being distributed via public app stores. 4

5 Personal managed (BYOD) If an organisation has a BYOD (Bring Your Own Device) policy in place, it is possible for IT to gain control over some aspects of the device and the operating system, via profiles. These are usually distributed OTA (Over The Air). Profiles allow IT to dictate certain settings and force a device to meet these settings, in order for apps to work. This can include, VPN settings, Passcode enforcement etc. Through installing these profiles, it can be possible for IT to take full control of the device. Apart from extreme circumstances, this is generally not advisable as many users will not accept the profiles and therefore, not use the corporate approved or created apps on their devices. A balance needs to be found between having enough control to protect corporate data and not taking liberties with the users device. Company owned If the devices are owned and distributed by the company then you can almost do what you want with them. Devices in this category should be managed via a MDM solution in order to control: VPN settings Passcode enforcement Pre-installed apps Inactivity lock time Device features: Siri (ios) Camera AirDrop (ios) icloud (ios) Profile Installation App store access Remote wipe Remote lock MAM vs MDM This is an important consideration when choosing distribution and security settings for your apps. The choice really boils down to whether you are implementing a BYOD policy, or whether the devices are corporately owned. 5

6 In some cases, it may be a blend of both depending on what organisations want to control. MAM (Mobile App Management) Mobile App Management is the way to go if you are implementing a BYOD policy. As the name suggests, it allows you to have control over apps and their data without infringing on the users personal usage of the device. One caveat to note is that MAM allows you to control only your apps, not third party apps. MDM (Mobile Device Management) Mobile Device Management is a much better solution, if the devices are owned by the organisation. As these are company assets, IT can have full control over the device and therefore limit the usage of them to purely work related tasks. MDM allows you to control a device at the OS (Operating System) level, not just the apps you have created. This obviously comes with its own issues. One of the reasons ios became popular in the corporate market was executives getting frustrated with not being able to use the devices they had as they wanted to. With the launch of ios 8, Apple has introduced further improvements to management of the device, data and apps; a key benefit for the corporate market. ios 8 provides a MDM framework, which allows IT to fully configure and manage all ios devices within an organisation. OS X Server includes Profile Manager, which is a MDM solution that allows companies to remotely manage ios devices. One benefit of many MDM and MAM solutions is that they can be used to separate personal and corporate data. It can also be used to disable personal apps and enable corporate apps in certain locations. Refer to appendix A for Gartner s Magic Quadrant for enterprise mobility management suites. App data Apps are generally only as good, or as useful as the data that is either served to them, or being generated by them. As a part of the initial planning phase, the data should be reviewed and classified as: 6

7 Public: Data that typically is publicly accessible requires minimal security controls and poses little or no risk to the company s reputation, resources, services, or individuals Private: Data whose unauthorised disclosure may have moderately adverse effects on an organisation's reputation, resources, services, or individuals. This is typically the default classification for most organisations and requires a moderate level of security Sensitive: Data whose unauthorised disclosure may have serious adverse effects on an organisation's reputation, resources, services, or individuals. Typically, this includes data protected under governmental or state regulations, or data that carries with it proprietary, ethical, or privacy considerations. Sensitive data requires the highest level of security. Sensitive data would usually encompass data such as user login credentials, banking details etc. States of data We usually refer to data in two states when developing apps: 1. Data at rest: offline, static data that is stored or cached on the device or server 2. Data in transit: data being sent to and from a device or server (the communications layer) Data at rest Data at rest, up until now, has always been stored on a server and served up by a web page. If you didn t have a connection, the web page would simply not load. Mobile has changed this and now users expect their data to be available even when they are not in range of WiFi or 3/4G networks. This essentially means storing a copy of something previously stored on a secure server on multiple devices potentially. The server is usually under the control of the content owner and measures are put in place to restrict access (physical and virtual) to the data. Once you have sent that data to the device however, it is out of your central control, so steps must be taken to protect data being store on the device. Any data being stored on the device should be classified using one of the three levels mentioned above (public, private, sensitive). Once this has been determined, the decision should be 7

8 made on whether it is being stored or not. If it is being stored, decisions need to be made about which methods should be used to protect it. Public: There is no need to encrypt any part of this data. It can be stored in text files and unencrypted data stores. Usually no form of authentication would be required to access this information Private: Would need to be stored in an encrypted data store or the users keychain Sensitive: Very sensitive data should not be stored on the device and all other avenues must have been explored before making this decision. If it is going to be stored on the device then it should be protected by encrypting the data and the data store Data in transit In the same way as data at rest should be reviewed, so should any network transmissions. Public: this can be transmitted over a HTTP connection, there is no requirement for any more protection than this, but ideally a HTTPS connection should be used if possible Private: Must be sent over a HTTPS connection Sensitive: Must be sent over a HTTPS connection, it is recommended to encrypt the data before sending and, if available, a VPN connection should be used as well. Encryption of data before transmission Instead of purely relying upon the SSL connection to protect the data, the data can also be encrypted on the device or server before sending. A decryption key would be required on the device or server, or both, to facilitate this. VPN Connections VPN connections can be used to ensure that data never leaves your network. VPN connections allow users to only access content on internal systems if they are authenticated at a network level. Access to any systems, such as Sharepoint, that may sit on the internal network, can also be secured with the usual username and password combination, meaning that many systems are behind two layers of authentication. 8

9 Certificate pinning Certificate pinning is a way of adding an extra layer to an HTTPS connection by, bundling the certificate from the server in the app itself. This means that all requests have to exactly match the certificate on the device with the certificate on the server. One of the main drawbacks of using this approach, however, is that the app needs to be updated whenever a new certificate is required. Considerations in development An HTTPS connection is enough to cover public, private and sensitive data while in transit. However, depending on the nature of the data being transmitted, you may want to consider one (or more) of the above additional layers. However, there are some things to consider surrounding the implementation of these layers: Performance: if data is being encrypted and decrypted on the fly then performance can suffer as a result. There are a number of factors to considered here, such as frequency of transmission and size of payload, before opting to do this Secure key generation: In order to encrypt or decrypt data, you must generate a key to use in the encryption process and subsequently in the decryption process. Deciding on the technology to use for this is an important decision. User Authentication Mobile apps and the servers they communicate with should be authenticated using a stateless, token based authentication model. Stateless authentication Mobile apps should be secured using a stateless authentication model. This means that no user state is ever stored on the server and that each individual request made by the client is authenticated. This is usually implemented by sending an authentication token in the header of every request where authentication is required. 9

10 Types of token There should be two types of token created when using stateless authentication: 1. Registration tokens: generated when a new user is created and stored against that user in the database. These should not be deleted unless the user is removed from the system or the account becomes compromised 2. Authentication tokens: generated when the user logs into the app. These can be deleted as and when required, to comply with any company policies surrounding session duration etc Generating tokens Tokens should be generated on the server using an acceptable encryption algorithm and not on the device. Once generated they should be stored against the user in the database. The device should have no need to decrypt an authentication token. It should only have to store it and know which requests require it. This provides several benefits: No sensitive user information is ever stored on the device for the purposes of authentication No decryption keys are ever stored on the device The server maintains control over access No encryption algorithms are stored on the device. Should the code become compromised the authentication code would not be The server retains control over access. Tokens can be deleted server side to force login or to block access completely Mubaloo recommends generating your tokens using Bcrypt. Authenticating a user Refer to appendix B. Recommended authentication model Any user wishing to use the mobile app, will be required to log in via the desktop portal first and generate a one time login code (2 factor auth). This code will be time limited and will be invalidated once the time has elapsed. 10

11 The user will be required to submit: Active Directory credentials Logon name Password Code generated on desktop portal Upon receiving the credentials, the code is validated and if validation passes, an authentication token should be generated using the users Active Directory password. This will create a key and a system wide salt (otherwise known as pepper ). This should then be stored against the user in the server side database. Once the token has been generated (and by definition, the user has been authenticated) the service should send back the user profile in the response body of the authentication / login call. Example HTTP headers An example HTTP request from a device with an authtoken: POST /login/ HTTP/1.1 Host: example.server.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en- US; rv: ) Gecko/ Firefox/3.5.5 (.NET CLR ) Accept: text/html,application/xhtml+xml,application/ xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7 X-Auth-Token: <generated token here> Pragma: no-cache Cache-Control: no-cache A salt is a randomly generated value based within the string in the database, so that using hash tables to crack passwords becomes impossible. As each password has its own salt, each one needs to be individually cracked. A pepper is a secret site-wide value based separately from the database. It s used so that if the database is compromised, it will not allow the entire app's passwords to be brute-forced. The server should be configured to look for X-Auth-Token on incoming request headers. The value of this field should be compared to the value stored against that user in the database. If the token is found, allow the response to be sent, however if the token doesn t match or does not exist, the response should be sent with the correct status code (a Unauthorised response). 11

12 Passcode protection If MDM is not available (meaning devices cannot be forced to implement a device-wide passcode), an app level passcode will be implemented. This passcode will have the same characteristics as a device level passcode and the following options will be configurable: Minimum length Passcode characteristics (must include numbers, special characters etc) Inactivity timeout Lifetime Passcode history rules (cannot be the same as previous n passcodes) Number of failed attempts These rules will be stored locally on the device and refreshed, each time the user logs in. Should the rules need to be updated, the users can be forced to re-authenticate by deleting all authentication tokens, in the User table. Passcode reset If the user enters an incorrect passcode n times (dependent on the configuration options received upon login) the users authentication token will be deleted from the device. The user will then be forced to re-authenticate and (upon successful authentication) set a new passcode. App behaviours In order to provide a secure but usable app, the right balance between UX and security needs to be met. If an app is so secure that it makes it difficult for users to use, all the money invested in the app will have been wasted. Systems with high security may also encourage users to circumvent the controls, by using other apps and services - this is generally when corporate data leaks out. Another scenario is if an app is 100% secure but is hard to use, the end users will circumvent the controls that the app is attempting to put in place. Generally, they will do this by using other apps and services to achieve their goals and this usually results in corporate data leakage. 12

13 Likewise if an app is so easy to get into, that there is essentially no protection at all, chances are your legal and Information Security teams will be dead against it. Either the project will never get off the ground, or the data will be so limited, it will prove useless to the user. Either scenario will potentially put barriers in the way of future app development projects by wasting time and money. Example An employee wants to access a sensitive document, for a client contact list on their smartphone, tablet and laptop, as they never know which one they will be using. This list is frequently updated, so access to it on all these platforms is essential. Due to strict IT policies, the app goes into the background after every 30 seconds of inactivity. This means the app requires a complex passcode to be used, every time. The employee gets frustrated with the app, so s a copy of the list to their private (non corporate) account. They also upload it to their Dropbox account where they can now access it, hassle free, from all devices. Good for the employee, bad for corporate data. You can see that a balance needs to be struck here. IT and Information Security consultants and teams are now considering this balance as well as the security and risks of exposing their data. If you are not currently considering this approach you probably should be, some control is better than no control. Implementing an app level passcode system There are several aspects to consider in designing and implementing the passcode protection system: Lifecycle events Mobile apps have several lifecycle events that need to be catered for, usually involving going in and out of the background: The user has elected to close the app (sending it into the background with the home button) The user has switched to another app The user has an incoming call etc The app needs to respond in an appropriate manner in each scenario. Mubaloo recommends, that an app should display the 13

14 passcode entry screen on re-launch after n seconds. (Value to be configurable based on settings from the API). Inactivity timers An inactivity timer, for forcing the user to re-enter their passcode, is also recommended. This should be long enough to allow the user to switch apps for a brief period to check something, but short enough to protect the app data. The timeout duration will be configurable via the API. Passcode rules Passcodes should be complex enough to meet your organisation s criteria but should not be so complex that users are likely to forget them. Again, it s all about finding the balance between security and usability. A secure password (complex string of characters, numbers and symbols) prompted for every time the user puts the app into the background will almost certainly result in the app not being used. Whereas a 4, 5 or 6 digit pin will be much less of a barrier and result in more use. We have usually gone for a 5 or 7 digit PIN, something that s not the same as the users bank card PIN, but also something that will put them off using their date of birth. You can also add validation to the PIN rules, looking out for regular patterns such as 1234 or 0000, but don t make this too complex. Ultimately, if a user wants to use their DOB or an easily guessable number there is not much you can do about it. Push notifications Never send sensitive or secure data via Push. Push notifications are handled by SSL connections, however payload data is visible to Apple as it passes through their APN servers. Mubaloo also recommends not including sensitive information in push titles, or body texts, as these will be visible when the message arrives. Streaming Media Securing streaming media is more complex than other web service requests. As there is no session in place, an alternative mechanism is required. This secures the connection between the device and the server while streaming video. 14

15 Temporary random URLs Temporary video URLs can be produced and sent back to the app upon request. These should be generated in a similar manner to the auth tokens. These URLs should also have a limited lifespan, so that they are destroyed within n seconds of creation. The contents of these URLs can be streamed via an SSL connection. Considerations: Not actually an authenticated call If the URL is guessed then access can be gained. A secure enough generated URL would lessen this risk This approach would allow for playback using the default media player component. Auth Token The header based approach to all the other calls can be used if we build a custom media player into the app. By using a custom media player, we will be able to set the auth token as usual and initiate playback. Apple TouchID API On supported devices (currently the iphone 5s, iphone 6 and iphone 6 Plus, running ios 8) Mubaloo recommends securing access to your app using the TouchID API instead of a PIN or passcode. Conclusion Mobile applications are inherently more secure than desktop applications due to sandboxing; the mobile operating systems have not copied the mistakes of their desktop predecessors. However data caching on devices throws up privacy and security concerns we did not previously encounter in the web world. Ultimately, it s all about balance. You need to find the right balance between what works for you from a data security perspective and what your users will accept from an access perspective, so make sure the right people are involved in the project. Do not leave IT or security out in the cold in favour of UX and do not let security run riot over the UX. 15

16 If the balance is not right your data will be leaked or your application will not be used and you will find it very hard to get buy in for future projects. 16

17 Appendix A Source: (Gartner, June, 2014) 17

18 Appendix B 18

19 Enterprise Mobility Consulting Developing Deploying Security guidelines for mobile app 3