This is Part 2 of a series on Security & Privacy for Mobile Apps.
In this Part 2 of the series, we will cover the elements of mobile apps, and some guidelines related to security and privacy.
Personal and sensitive information include any critical information such as credit card numbers, credit card validation codes, social security numbers, driver’s license numbers, name, addresses and date of birth, and other Personally Identifiable Information (PII). Such class of information must be properly handled and secured.
Recall from Part 1 the main classes of “privacy functions” performed by mobile applications:
- Class A — Collects data
- Class B — Stores data
- Class C — Shares data
- Class D — Tracks the user
- Only collect, store, share, track if really needed; vs. collecting information “just in case for potential future use”, and,
- Preventing others from gaining access to the sensitive data collected by your app (that is, protecting the information), and,
- Communicating to the user what the app does with respect to sensitive data (via private policy page).
Let’s go a step deeper in understanding how the security and privacy functions listed above may affect your mobile application; to better visualize this let’s look at the following diagram which illustrates the typical elements of a mobile application with annotations on security and privacy:
In this diagram we can see the user interface, access to local storage, network transmissions/access to remote information and/or APIs, sharing, and other — most if not all parts of the mobile app have security and privacy considerations:
1. The Device/Smartphone/Tablet
- Your application — your app, native or webapp.
2. Graphical User interface with its screens, widgets, navigation, web-views, etc.
- Protect access to critical app paths/screens with a PIN — prompt the user for PIN
3. Local store
- This can be a local DB, the filesystem, configuration files, preferences
- All sensitive data in local store must be encrypted, using a unique secret key
- For key generation use the PIN from the user + a device unique ID; calculate the hash, store the hash – do not store the PIN. Recalculate the hash dynamically for comparison/key-validation
- Examples of sensitive data: payment-information, cardholder information, related 2D barcode images
- Store critical files on the app’s storage area (vs. public storage) so that such information is automatically removed when the application is uninstalled
- If utilizing an encrypted database, be aware of potential performance issues — encrypting/decrypting data are expensive operations!
4. The Network / Data transmissions
- Most apps are connected to the cloud — to invoke a service on the web, to push analytics data, other
- All data over the network shall be encrypted — use HTTPS/TLS, VPN
- Depending on your app requirements, you many have to encrypt your messages using additional encryption + keys
- Consider tokenization — critical information shall be tokenized; don’t use information such as Social Security numbers, drivers licenses directly; tokenize such
- All data between the device and the server shall be encrypted as previously described
5. Context Information – this is information like time, geo/location, sensor/ambient data, preferences, social, other
- The user shall be notified if ambient, social or profile information is utilized by the application
6. External services/servers — Analytics, Facebook, Twitter, etc
- The problem is that often “how and when” related data is “collected and shared” is totally out your apps’ control
- Make sure you protect yourself — the user shall be notified about things like analytics-data being collected/utilized by the app.
7. The Activity Log is used to record key activity information that can be used for debugging or support purposes, and that may or not be accessible remotely.
- Encrypt the activity log on local store
- Encrypt activity log when/if transmitted
8. Your App Servers on the Cloud
- Designing a secure network architecture is important
- (a) Use DMZ for publicly visible servers
- (b, c) Servers with sensitive data shall resides behind a firewall
- (d) All server DBs shall be properly protected and encrypted if possible
Tokenization & Encryption
Tokenization and encryption were mentioned a couple of times on the annotations/guidelines above; let’s expand a bit on this. Tokenization & Encryption are two ways of protecting sensitive data.
Tokens are abstractions used to hide real data. Tokens are used as substitutes to Personally Identifiable Information such as SSNs. A simple example of a Token is a customer id (vs. using SSN):
- Avoid storing personal identification; instead use the Tokens to access critical information,
- Because the actual critical information doesn’t have to reside locally, the location of the critical information can be centralized, helping minimize sources of leakage.
- But this comes with a price: Tokens must then be created, mapped/substituted, and managed.
And of course, Encryption is a very important way of protecting sensitive information. Always encrypt data that must be stored and/or transmitted. Encryption also comes with a price:
- You may need to identify and implement the encryption functionality explicitly,
- You may have to select specific algorithms (such as AES) and key-sizes (such as 1024) depending on your business needs,
- You have to deal with key management — key generation (for example, based on PIN and device unique ID), storage, and other related key-management,
- There are performance implications.
Encryption and tokenization are not mutually exclusive and you should consider using both techniques on your mobile application.
To conclude this article, I am including some related guidelines that I originally wrote back in 2004; still very applicable today.
Summary General Guidelines for Mobile Applications with Sensitive Data
Always Alert the User
- This privacy notice must be properly localized (i.e. right language for the particular country) and must be explicit.
- This privacy notice must be displayed and acknowledged, at least once (probably the first time the application is used). This acknowledgement must be recorded. Note that recording the acknowledgement also serves to protect you, validating you did your part notifying the user.
- This privacy notice should be re-displayed every once in a while, lets say once a month, or once a quarter, or something that is configurable, but the notice should never be disabled.
The End-User, the Ultimate Decision Maker
- The application must provide the means to turn off location tracking at ANY time. Always give the device-user the ultimate decision for being tracked or not, for using geo-location information or not!
Safeguard All Captured Information
- Location information and ALL personal information, if stored on the device, must be safeguarded: 1) not accessible by other programs or entities, 2) and possibly encrypted.
- Location information and all personal information, if transmitted, must be properly encrypted.
- And if stored on the server, must be totally safeguarded (access-control, encrypted).
Use the User Context responsibly
- The mobile context can provides awesome information to your application; for example, you can use location information for location-based reminders.
- Geofencing, the ability to track using GPS or Wi-Fi (or other means) when a person crosses a pre-defined boundary or area, can be a scary thing if used for tracking others. Don’t use geofencing to track others.
- Always ask for permission.
Stay tuned for Part 3 of this series which covers the Payment Card Industry Security Standards and related-guidelines.
- Security & Privacy on Mobile Apps, Part 1 – Introduction
- Security & Privacy on Mobile Apps, Part 2 – Typical Security Elements of a Mobile Application
- Security & Privacy on Mobile Apps, Part 3 – PCI Compliance