iOS SDK - Security Requirements
Paydiant's SDK is a hardened set of libraries designed for secure communication to the Paydiant Managed Service. The SDK leverages an independent module developed specifically by Paydiant for secure, orchestrated network-related operations between the network module and the Paydiant Managed Service.
Your mobile application is required to adhere to the following security requirements designed to maintain the security of the mobile application, consumer personal information, and the Paydiant Managed Service.
The mobile application will interact with the consumer and the Paydiant Managed Service (through the SDK). As a cloud-based platform, the goal is to store as little information as required on the mobile device and rely on the secure managed services for maintaining confidentiality and integrity of information. Information must be protected appropriately while being used by the mobile application.
Data on the mobile device must be protected as outlined below.
|Data Types||* Card Data (PAN, Expiry, CVV)
* Consumer Password/Passcode
|* Consumer Address
* Tokenized Card Data
|* Paydiant URI Strings (non-card referencing)
* Consumer Username
* Offer Data
* Loyalty Data
|Approved Mobile Storage Locations||No permanent mobile storage permitted||No permanent mobile storage permitted||Any|
|Storage protection required||* Card Data wiped from memory after useful life.
* Login credentials masked on entry.
|Purge on app in background||Required||Not Required||Not Required|
|Purge on session termination||Required||Required||Not Required|
|Purge on device unlink||Required||Required||Required|
|Purge on app removal||Required||Required||Required|
Unintentional data storage
Data can be captured in a variety of artifacts - many unintended. If data is ever transmitted as query string parameters, as opposed to in the body of a POST request, then these are liable to be logged-in various places - for example, within the user's browser history.
You are required to validate that you have verified the types and protections of data stored in log/debug files, cookies, web history, web cache, property lists, files and QLite databases.
Clear App Memory of All Sensitive Data
Paydiant’s wallet issuer partners have an obligation to ensure sensitive data that is input into the device during registration and account management operations is not persisted in the app’s memory following completion of the operation.
Specifically, when sensitive data is by a mobile wallet user for the purpose of populating
PDPaymentAccount data objects, developers should create a mutable copy in the app memory from which the data can be retrieved when needed for the operation, then should wipe the app memory to clear the values once the operation has completed. In particular, the following API calls populate the
PDPaymentAccount data objects and are applicable to data wiping in the app:
- RegisterNewUser (Paydiant)
- RegisterCustomer (SSO)
Secure Data Entry
Card holder data must be masked upon entry into the mobile device, preferably per-digit. This includes:
- Credit Card Number
- Credit Card Expiration Date
- Credit Card Security Code
If the mobile application enters the background directly from a card holder data entry screen, protections must be in place to ensure that automatic OS-level screenshots cannot capture any card holder data.
The default design should be to mask and/or provide partial (e.g. last 4) card holder data when presenting or storing.
Protecting your application from reverse engineering is a critical step in maintaining the integrity of a services platform. Code obfuscation protects the code base from decompiling and modification using obfuscation algorithms, overlapping checksums injections, flattened code paths, and embeds platform-specific anti-debug and anti-piracy code. Using checksums, digital signatures and other validation mechanisms on files used in the application can help detect whether data files have been tampered with in an attempt to manipulate the application, and can also ensure any data files are authentic by enforcing a signature embedded within the application.
If your application detects that tampering has occurred, it is recommended to notify the end user and log the event to the managed service. You may choose to take more direct action, such as wiping all stored data from memory and terminating any active authenticated sessions.
ASLR, introduced in iOS 4.3, randomizes how an app is loaded and maintained in memory. ASLR randomizes the address space used in the application, making it difficult to execute malicious code without first causing the application to crash. It also complicates the process of dumping allocated memory of the application.
Your iOS application must utilize full ASLR protection and must be compiled with support for PIE (position-independent executable).
OWASP Top Mobile Controls
The Open Web Application Security project (OWASP) and the European Network and Information Security Agency (ENISA) collaborated to build a joint set of controls for protecting mobile applications. Mobile applications interacting with the Paydiant Managed Service through the Paydiant SDK must be designed and validated in-line with the current OWASP Top Mobile Controls. As of the writing of this document, those are:
- Identify and protect sensitive data on the mobile device.
- Handle password credentials securely on the device.
- Ensure sensitive data is protected in transit.
- Implement user authentication, authorization and session management correctly.
- Secure data integration with third party services and applications.
- Pay specific attention to the collection and storage of consent for the collection and use of the user's data.
- Implement controls to prevent unauthorized access to paid-for resources.
- Ensure secure distribution/provisioning of mobile applications.
- Carefully check any runtime interpretation of code for errors.
Prior to being certified for use on the Paydiant platform, your mobile application must undergo mobile application security testing from a mutually agreed upon, suitably qualified organization. Paydiant can provide reference contacts at a number of mobile application security testing firms if necessary. If you have an internal team that specializes in mobile security and penetration testing, you may use your own team.
The tested application version must be release candidate quality, with all major features implemented. All major releases and any release that significantly alters the authentication, payment flow, communications or data storage of the mobile application must be validated.
Paydiant will review the output of the testing and any material findings must be mitigated prior to certification and subsequent release to either the Apple App Store or Google Play.
While jailbroken devices do pose additional security risks to user data, the negative impact of jailbreak restriction to valid users has proven greater than the potential protection afforded mobile wallets installed on compromised devices.
Based on this data and standard practices employed by the majority of financial apps in the market at large, Paydiant does not advise preventing users of jailbroken devices from installing or utilizing mobile wallet applications developed with the Paydiant mobile SDK.
As always, app developers working with the Paydiant platform are responsible for employing best practices in security for sensitive data handling to minimize risk.